Le 13/02/2021 à 18:01, Levi Morrison via internals a écrit :
You make some good points, Pierre. Here are my main rebuttals:
1. "Spl" is already the effective namespace for the SPL because
that's the prefix used by SplFixedArray, SplQueue, spl_classes, and so
on. Its namespace has already been de facto chosen.
2. We have two proposals adding new things to the SPL for 8.1, so we
need to decide if they are going into ext/spl as 1. \Spl\Thing, 2.
\SplThing, or 3. \Thing. Keeping the wider vision in mind is a great
principle, but we need to decide on these new additions _now_ despite
not reaching consensus on the wider thing.
Obviously, I'm hopeful we can agree on using the Spl namespace for
these additions, and any future SPL additions.
[1]: https://wiki.php.net/rfc/any_all_on_iterable#vote
Aside of the fact I don't like "Spl" if a good naming convention comes
out with it prefixing all namespaces so be it and I'll be happy. One
thing that bother me much in the current proposal is those kind of
classes: `Spl\FixedArray -> SplFixedArray`.
That's the most important point in my eyes, it should be already named
with a deeper namespace, such as:
`Spl\[Collection|List]\{FixedArray,Vector,Queue,LinkedList,...}`
in order to make space for later other namespaces to take their rightful
place, such as:
`Spl\Security\{PasswordHash,RandomNumberGenerator,...}` or
`Spl\[Io|File|FileSystem]\{FileBuffer,DirectoryIterator}`.
Even if it starts with a narrow scope, it *must*, in my opinion, make
space for later additions, therefore `Spl\` must be considered as being
the "PHP standard library root namespace", in that regard, no classes or
functions must live at root, they must be segregated in their own
sub-namespace. If we don't do this, we will very much regret it later.
Regards,
--
Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
