Re: Re: Proposal: namespace the SPL

From: Date: Sat, 13 Feb 2021 17:57:34 +0000
Subject: Re: Re: Proposal: namespace the SPL
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-113168@lists.php.net to get a copy of this message
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

« previous php.internals (#113168) next »