On Sun, Feb 14, 2021 at 5:51 PM Levi Morrison <levi.morri...@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 <tysonandre...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
