On Sat, Feb 13, 2021 at 10:57 AM Pierre R. <pierre-...@processus.org> wrote: > > 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 >
To be clear, I am arguing that `Spl` be the namespace for future additions to `ext/spl`, and that we alias a few existing types for consistency. Just as `ext/spl` is not the whole PHP standard library (just one small part of it), the `Spl` namespace I am proposing is not the "PHP standard library root namespace" either; it's just the namespace for the bits in `ext/spl`. What you are arguing for was the subject of recent namespacing proposals, which failed to reach consensus. I am intentionally proposing a different solution for a much narrower problem hoping it will stick, so that new additions going into the ext/spl can avoid having this naming discussion every time. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
