Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113172
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>
In-Reply-To: <DM6PR07MB661878F5DE5B10176DB4F77FF9899@DM6PR07MB6618.namprd07.prod.outlook.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Sun, 14 Feb 2021 17:51:43 -0700
Message-ID: <CAAKU0u=Puwqhqk2_HaaWW+2Oi6UcWyu-qe8KDjMwCMg=dO16bg@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")

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).