On Thu, Feb 11, 2021 at 10:48 AM Chase Peeler <chasepee...@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 <marand...@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 > chasepee...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
