Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113145
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>
In-Reply-To: <CAPKYkKw4QcogrucjC9XAszb02Qpd5E8cuZyVZ33n=fUOaq378g@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 11 Feb 2021 10:54:53 -0700
Message-ID: <CAAKU0umO=Kq-swnWs=0MwHbS4_xgViKWuhMgoBqFKEv9LCzYvg@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Mark Randall <marandall@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: Proposal: namespace the SPL
From: internals@lists.php.net ("Levi Morrison via internals")

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@l=
ists.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 bec=
ause:
>> > >   1. It is focused on a specific area which already has an establish=
ed
>> > > "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 (`ReverseIterato=
r`
>> > > 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 b=
e Spl or SPL though). How feasible is it to create generate a deprecation n=
otice when the global version is used? I assume the hope is to eventually m=
ove away from using those, and I don't think that's a horrible BC break giv=
en 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