Re: Re: Proposal: namespace the SPL

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 ‚¡VUBÿ*“+uÛ¿ÿ > > iÈ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.