Re: Re: Proposal: namespace the SPL

On Thu, Feb 11, 2021 at 10:48 AM Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Thu, Feb 11, 2021 at 12:23 PM Levi Morrison via internals <internals@lists.php.net> > wrote: >> >> On Thu, Feb 11, 2021 at 9:57 AM Mark Randall <marandall@php.net> wrote: >> > >> > On 11/02/2021 16:39, Levi Morrison wrote: >> > > Let me know what you think. I am hopeful this approach will work because: >> > > 1. It is focused on a specific area which already has an established >> > > "namespace", but in name-only (not technically). >> > > 2. It does not try to solve the larger problem, which has a lot of >> > > disagreement. >> > > 3. I will be proposing new types for ext/spl soon >> > > (ReverseIterator >> > > and an array iterator that is more efficient than >> > > \ArrayIterator), >> > > and Tyson Andre has already proposed >> > > CachedIterable and company >> > > which is in ext/spl, so this space has active >> > > development. >> > > >> > > Thank you for your time. >> > > >> > >> > Do you want a dumping ground? Because this is how you create a dumping >> > ground :-) >> > >> > If we're going to start putting things into namespaces (and we should) >> > then we should absolutely avoid repeating the mistakes of the past by >> > dumping completely unrelated things together. >> >> I agree, which is the point of accepting things in a narrow scope. >> Data structures and iterators go hand-in-hand, as many iterator >> implementations are directly connected to the internal implementation >> details of the related data structure. There are other iterators, and >> as long as they are general purpose they are fine too. These things >> are related, not unrelated. >> >> > If SPL\ is to exist (and personally I think SPL is so cancerous, it >> > shouldn't) then IMO it must absolutely be SPL\iterators. >> >> As mentioned in the previous point, iterators and data structures >> belong together. It does not make sense to separate the implementation >> of FixedArray and its iterator into two different namespaces; they are >> one cohesive unit. >> >> Lastly, if we don't adopt a namespace soon, what will new names be? I >> can guarantee it will be something like SplReverseIterator, >> not >> SplIteratorReverseIterator. It won't be >> SplDatastructureCachedIterable, it would be something like >> SplCachedIterable (or >> CachedIterable, ugh). >> >> As you see, "Spl" _is_ the namespace. Any more or any less is >> incongruent with what we have. This is why I am hopeful that >> _specifically_ using "Spl" for these specific types can reach >> agreement; all we are changing is Spl$thing to >> Spl\$thing. >> > > I think Spl makes sense (there might be a debate over whether it should be Spl or SPL though). > How feasible is it to create generate a deprecation notice when the global version is used? I assume > the hope is to eventually move away from using those, and I don't think that's a horrible > BC break given that users have enough time to prepare for it. I don't know the answer to that question. However, I don't think we should add a deprecation on the very first version that we add the aliases anyway. I think that would make for a bad upgrade experience from 8.0 to 8.1. I would leave that more for 8.3, 8.4-ish in the release cycle so there are at least a few versions for people to organically change their code without triggering any notices of any kind. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> > > > -- > Chase Peeler > chasepeeler@gmail.com