Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113173
MIME-Version: 1.0
References: <CAFMT4Nq5Ai2_oA02jJ6GJUu4dDRtEvsBWa=_mze_YHbzNW0vfw@mail.gmail.com>
 <60256200.1c69fb81.46e68.6437SMTPIN_ADDED_MISSING@mx.google.com>
 <CAAKU0un-vFD+VE0+hPTX6S4XWap_37RP9tNpyzkh3NMarFeiGg@mail.gmail.com>
 <CAPKYkKw4QcogrucjC9XAszb02Qpd5E8cuZyVZ33n=fUOaq378g@mail.gmail.com>
 <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org> <CAAKU0u=r16jKWQ+eiRasr3fmpx5jM1vgKe8c7AX-JxewdnqFiA@mail.gmail.com>
 <26dffe34-135a-68c9-b202-0726f3f78d04@processus.org> <CAAKU0unsBZnL7sjvK+CZZ7um0HqWoQX=zUcY+SHcGBsTtjhDRQ@mail.gmail.com>
 <DM6PR07MB661878F5DE5B10176DB4F77FF9899@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAAKU0u=Puwqhqk2_HaaWW+2Oi6UcWyu-qe8KDjMwCMg=dO16bg@mail.gmail.com>
In-Reply-To: <CAAKU0u=Puwqhqk2_HaaWW+2Oi6UcWyu-qe8KDjMwCMg=dO16bg@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Sun, 14 Feb 2021 18:03:04 -0700
Message-ID: <CAAKU0ukw-PFmLtgQy0ntjFAXiDuLUnz_hjKbYQwLsS3po2HD7w@mail.gmail.com>
To: tyson andre <tysonandre775@hotmail.com>
Cc: "Pierre R." <pierre-php@processus.org>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: Proposal: namespace the SPL
From: internals@lists.php.net ("Levi Morrison via internals")

On Sun, Feb 14, 2021 at 5:51 PM Levi Morrison
<levi.morrison@datadoghq.com> wrote:
>
> Oof, this is a long one. I'm going to snip some of it  but respond to
> most things privately; I will also respond to some things publicly
> later.
>
> On Sun, Feb 14, 2021 at 3:44 PM tyson andre <tysonandre775@hotmail.com> wrote:
> >
> > Hi internals,
> >
> > > > 1b. We may switch the direction of this alias in 9.0.
> >
> > The new names for existing Spl types at least seem more readable and possible to polyfill with `class_alias`.
> > It should be clarified if "data types" include interfaces such as https://www.php.net/manual/en/class.splobserver
> > but I assume it does.
>
> <snip>
>
> > Do you have an expected timeline for creating the RFC document for this proposal and starting the vote?
> > A vote would greatly reduce the uncertainty and time/energy involvement of proposing
> > adding additional datastructures, benefiting contributors both familiar and unfamiliar
> > with the PHP RFC process, and I agree with Levi that it would be useful to ensure that
> > "new additions going into the ext/spl can avoid having this naming discussion every time."
>
> I will write a formal RFC this week, and it will include all of the
> proposed aliases (unless the sentiment is that we don't want them; I
> talk about this a bit more later in this email).
>
> > **My main objection to the proposal is that this forces
> > all core generic datastructures to go in the Spl namespace
> > indefinitely, or would entail the creation of a separate module and splitting up the php.net manual pages to document new built-in datastructures
> > that don't begin with `SPL\`.**
>
> This is a logical conclusion from how it was worded, but it's not what
> I meant. I meant to say that ext/spl is open for contributions in
> certain spaces:
>  1. Generic data structures and their iterators. (not highly specific
> ones, like a hypothetical LaravelEventQueue).
>  2. Generic iterators.
>  3. File oriented types (I omitted this originally, but it was unintentional)
>
> Anyone can propose new additions to ext/spl and if they are in that
> scope (and maybe a few more like exceptions, we'll see), but they
> aren't forced to go into the SPL. It probably makes sense to add it to
> the SPL, but if there was a large proposal, like an iterable oriented
> library with over a dozen symbols, then I'm sure a case can be made
> for putting it somewhere else too.
>
> > If we were to enforce that all new datastructures introduced
> > into SPL started with `SPL` I'd have to consider moving the `CachedIterable` proposal to `ext/std` or a
> > new always-enabled module such as `std_ds` for classes introduced in PHP 8,
> > but if it turns out there's widespread support for the namespace choicing of `Spl\...ForwardArrayIterator`
> > I would very likely go with `Spl\...CachedIterable`.
> >
> > - I'd proposed `CachedIterable`, not `SplCachedIterable`.
> > - It'd force a choice between inconsistencies.
>
> In my opinion, we shouldn't be adding very many symbols to the global
> namespace that are unprefixed. Things should be namespaced either by
> using a real namespace (preferred) or by a prefix. That isn't to say I
> would outright ban it -- there could be perhaps new core interfaces
> that may make sense to go there if they interact with the language in
> special ways. Or at least, they belong in the global namespace by
> status quo until we can agree on an official namespace policy for
> such.
>
> >   I would find it inconsistent to use the Spl naming scheme both for classes with extremely old design decisions
> >   from php 5.3 <snip>
>
> This does not bother me, but I would also be open to not aliasing
> existing types if that would make people happier. If we don't alias
> the existing types, then there will be a small `Spl` namespace with
> only newer additions (which are probably of higher overall quality
> than the prefixed versions). I am okay with this, but sometimes people
> feel like this kind of thing is too small in scope.
>
> >   It'd also be inconsistent to have two different sections in the PHP manual for datastructures because of a constraint on the folder `ext/spl`.
> >   I guess phasing out `SplStack` and so on to switch to recommending brand new redesigned datastructures such as `PHP\std\Vector` or `PHP\ds\Vector`
> >   would be another option.
> > - Right now, SPL is a mix of classes/interfaces/functions prefixed with Spl and those that aren't,
> >   if you look at https://www.php.net/manual/en/book.spl.php ,
> >   SPL already has data structures such as `ArrayObject` and interfaces that aren't prefixed.
>
> Yes, the SPL is not fully consistent. Some of these things have moved
> out of the SPL over time (such as the Countable interface).  Most data
> structures are prefixed, but no iterators are. In other words, it has
> some warts but at least mostly has a pattern going. As mentioned
> earlier, I think nearly all new symbols need to be namespaced or
> prefixed, so I think it's worth breaking the no-prefix, no-namespace
> tradition of the iterators for new iterator types (at least concrete
> ones; there may be room for new interfaces in the core language).

Oops, didn't send it privately after all. That's fine; I was just
going to try to be more concise and general for the public one.