Re: Re: Proposal: namespace the SPL
| From: | Levi Morrison via internals | Date: | Sat, 13 Feb 2021 19:45:04 +0000 |
| Subject: | Re: Re: Proposal: namespace the SPL | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-113169@lists.php.net to get a copy of this message | ||
On Sat, Feb 13, 2021 at 10:57 AM Pierre R. <pierre-php@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.