Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113171
To: Pierre R. <pierre-php@processus.org>, Levi Morrison
	<levi.morrison@datadoghq.com>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Re: Proposal: namespace the SPL
Thread-Index:
 AQHXAJqf59VBi1ZMG0C2Ap92+tycAKpTOvyAgAMNcwCAAAouAIAAD5cAgAAeCQCAAXSJ8w==
Date: Sun, 14 Feb 2021 22:44:36 +0000
Message-ID:
 <DM6PR07MB661878F5DE5B10176DB4F77FF9899@DM6PR07MB6618.namprd07.prod.outlook.com>
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>
 <83fb79ae-13ff-09e7-83ac-3dcf4da4c3ad@processus.org>
 <CAAKU0u=r16jKWQ+eiRasr3fmpx5jM1vgKe8c7AX-JxewdnqFiA@mail.gmail.com>
 <26dffe34-135a-68c9-b202-0726f3f78d04@processus.org>,<CAAKU0unsBZnL7sjvK+CZZ7um0HqWoQX=zUcY+SHcGBsTtjhDRQ@mail.gmail.com>
In-Reply-To:
 <CAAKU0unsBZnL7sjvK+CZZ7um0HqWoQX=zUcY+SHcGBsTtjhDRQ@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [j9yfkg+Up0UTJs4Cc441BfEEcntD5Dxk7f2+j0zKLgHgM4IOPv7DUNYU1hzpzieo]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 492a0fc2-01da-4bb1-9b45-08d8d13a1acb
x-ms-traffictypediagnostic: CY1NAM02HT266:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 MqosZzXDiGuWd35DBpCqRoTNmCKICCpb4qIO8uT56Bn3c5nmG1RhTJsLl1IPcMz8oExlno1SYADmGn8xykSInztRUQ/aNjTTsww2KZ6MzjJLTtm8uP6aQmAasHG5mlcsUnuDeERZv3IEMoF21IVPJp7YtMWymxB1CkEDFTQ2paPvHOGGtL3khjjf7wkFQ61YXhrORqOKT1jI5GynAl4I5RfSywULpamTznVSR6ZSTl8llvE68W524EcMbIICR20HhabaB1kse/kKu3Lx/uKrh3CoUCr01R1Zw1jh2H208K26ccqJVcc1ahi2OQAhCpd0QzI2W5XPLN3Ry7x9w0igy8x/QR05n72+rSi49Fs5e6vn2Jesuwo2GOvCKaXTDUEdZexgBTVQ4KQObcbGaYTMQ7pkRqAQcac7z3LAlaiQUS0MsZPoJmZ8fIKjF3YEWQHz
x-ms-exchange-antispam-messagedata:
 eDnAnfkndARN2qaMZAPkUcrYLggKRsyGIASf1QJHIBOXuVBDG0/edZmK4RJy7D+BSDikiRflwtz3eM6ALf6lzkQBSNJUEXgAqADWISY8ie+qVdnYE6fAoWIRMTeI2z7V+zANKlyqpuLevjnv+HkShs7sxT+nU7USwls2VjGbFPOeDLAiFzDMrFN95DK49BicgeeZk6r2NNXD6UcRIzgm9Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT039.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 492a0fc2-01da-4bb1-9b45-08d8d13a1acb
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2021 22:44:36.0235
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT266
Subject: Re: [PHP-DEV] Re: Proposal: namespace the SPL
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
> > 1b. We may switch the direction of this alias in 9.0.=0A=
=0A=
The new names for existing Spl types at least seem more readable and possib=
le to polyfill with `class_alias`.=0A=
It should be clarified if "data types" include interfaces such as https://w=
ww.php.net/manual/en/class.splobserver =0A=
but I assume it does.=0A=
=0A=
A minor concern is that the wider switch on a case-by-case basis to namespa=
cing will collectively add a =0A=
lot of small barriers for end users that are upgrading (especially with ext=
ernal libraries/applications),=0A=
but agree that starting out small is the best way to discuss it.=0A=
=0A=
- e.g. data `serialize()`d and put into memcached or a database by PHP 9.0 =
=0A=
  could not be read from memcached by servers still running PHP 8.0,=0A=
  and this would unexpectedly result in PHP_Incomplete_Class =0A=
  and new users may need to do a lot of research to figure out how to avoid=
/fix this =0A=
  (by calling `class_alias` in 8.0).=0A=
=0A=
> > Let me know what you think. I am hopeful this approach will work becaus=
e:=0A=
=0A=
I support voting on this separately from adding new functionality.=0A=
=0A=
To clarify my earlier decisions, I had strong reservations about introducin=
g new functionality and setting a de facto precedent for a namespace policy=
 in the same vote=0A=
on https://wiki.php.net/rfc/any_all_on_iterable (but did so anyway due to f=
eedback of multiple voters suggesting widespread opposition to continuing g=
lobal namespacing months ago),=0A=
because the deciding factor in a vote on new functions or new classes for v=
oters may have been=0A=
"do I (dislike the namespacing choice used in this RFC) less than (I dislik=
e not having this useful proposed enhancement added to PHP)."=0A=
and am happier with your plan to create an RFC asking "do 2/3rds of people =
think this namespace choice should be used for future additions to ext/spl.=
"=0A=
=0A=
In my decision to independently gather feedback for https://wiki.php.net/rf=
c/any_all_on_iterable_straw_poll_namespace=0A=
I was deliberately overcommunicating knowing that:=0A=
=0A=
1. If it passed, the namespacing policy choices made there might be interpr=
eted or insisted on=0A=
   as a precedent for future additions to the Spl (or even PHP in general) =
for a long time.=0A=
=0A=
   This may cause a tolerable namespace choice to be used for many future a=
dditions to ext/spl, rather than the one preferred by most of internals,=0A=
   which is why I was only fine with starting a vote after gathering feedba=
ck from https://wiki.php.net/rfc/any_all_on_iterable_straw_poll_namespace=
=0A=
2. If it was voted on without gathering widespread feedback on overall name=
space preferences,=0A=
   I'd expect even more No votes and the function namespacing discussion co=
uld continually get reopened if some namespace permutation wasn't even an o=
ption.=0A=
=0A=
   I apologize for the 11-way straw poll.=0A=
   Many voters do not comment on the internals mailing list, e.g. if someon=
e else has already said the same thing.=0A=
=0A=
> > Let me know what you think. I am hopeful this approach will work becaus=
e:=0A=
> > =0A=
> > It is focused on a specific area which already has an established=0A=
> > "namespace", but in name-only (not technically).=0A=
> > It does not try to solve the larger problem, which has a lot of=0A=
> > disagreement.=0A=
> > I will be proposing new types for ext/spl soon (ReverseIterator=0A=
> > and an array iterator that is more efficient than \ArrayIterator),=0A=
> > and Tyson Andre has already proposed CachedIterable and company=0A=
> > which is in ext/spl, so this space has active development.=0A=
> > Thank you for your time.=0A=
> =0A=
> Do you want a dumping ground? Because this is how you create a dumping=0A=
> ground :-)=0A=
> =0A=
> If we're going to start putting things into namespaces (and we should)=0A=
> then we should absolutely avoid repeating the mistakes of the past by=0A=
> dumping completely unrelated things together.=0A=
> =0A=
> If SPL\ is to exist (and personally I think SPL is so cancerous, it=0A=
> shouldn't) then IMO it must absolutely be SPL\iterators.=0A=
> =0A=
> Without that all we've done is swap one problem for another.=0A=
> =0A=
> The idea of putting data structures next to generic iterator helpers is,=
=0A=
> quite frankly, nuts.=0A=
=0A=
Do you have an expected timeline for creating the RFC document for this pro=
posal and starting the vote?=0A=
A vote would greatly reduce the uncertainty and time/energy involvement of =
proposing =0A=
adding additional datastructures, benefiting contributors both familiar and=
 unfamiliar=0A=
with the PHP RFC process, and I agree with Levi that it would be useful to =
ensure that =0A=
"new additions going into the ext/spl can avoid having this naming discussi=
on every time."=0A=
=0A=
**My main objection to the proposal is that this forces =0A=
all core generic datastructures to go in the Spl namespace=0A=
indefinitely, or would entail the creation of a separate module and splitti=
ng up the php.net manual pages to document new built-in datastructures=0A=
that don't begin with `SPL\`.**=0A=
Right now, the collection of classes in SPL is fairly small - it's used in =
library code but rarely used directly,=0A=
but if PHP were to add a collection of datastructures similar to [`php-ds`]=
(https://www.php.net/manual/en/book.ds.php)=0A=
then end users would use the naming much more often.=0A=
=0A=
I'd agree that the prefix `Spl` in class/interface names has a large number=
 of negative connotations for those who=0A=
are familiar with it and my impression was that there'd be less than 2/3 su=
pport for a proposal to adopt it,=0A=
due to those negative connotations, the wide range of preferred namespace c=
hoices, and anticipations for future namespacing choices in PHP.=0A=
(Right now, I'm not even sure about 2/3rds for any proposed namespace chang=
e)=0A=
For those that aren't familiar with it, the name SPL may be hard to remembe=
r,=0A=
especially after namespaces get introduced for existing and new extensions.=
=0A=
For example, a well-known issue is that =0A=
https://www.php.net/manual/en/class.splstack.php extends `SplDoublyLinkedLi=
st` and implements `Iterator`=0A=
and isn't final, meaning:=0A=
=0A=
1. It is impractical to change for backwards compatibility reasons,=0A=
2. A doubly-linked list wastes memory and is slower for common operrations =
compared to something backed by an array.=0A=
3. Can't independently iterate over it while another iteration is in place =
and iteration has unknown side effects.=0A=
=0A=
   From user notes, "the `SplStack` is simply a SplDoublyLinkedList with an=
 iteration mode `IT_MODE_LIFOs and `IT_MODE_KEEP`"=0A=
4. If this RFC were to pass, what would we call a more memory/cpu efficient=
 array-based list, stack, or queue? `Spl\ArrayQueue`?=0A=
5. Consequently, many people prefer plain arrays over spl datastructures.=
=0A=
=0A=
I haven't actually checked, but I'd assumed at the time, some prefix (i.e. =
`Spl`) was chosen to avoid conflicting with user-defined `Stack`/`Queue`/ot=
her, etc.,=0A=
and that early on with namespaces only being introduced in PHP 5.3 it would=
 have been easier to create polyfills (for PHP 5.2)=0A=
if namespaces weren't used - it was an **acceptable** prefix, not the best =
naming convention.=0A=
=0A=
If we were to enforce that all new datastructures introduced =0A=
into SPL started with `SPL` I'd have to consider moving the `CachedIterable=
` proposal to `ext/std` or a=0A=
new always-enabled module such as `std_ds` for classes introduced in PHP 8,=
=0A=
but if it turns out there's widespread support for the namespace choicing o=
f `Spl\...ForwardArrayIterator`=0A=
I would very likely go with `Spl\...CachedIterable`.=0A=
=0A=
- I'd proposed `CachedIterable`, not `SplCachedIterable`.=0A=
- It'd force a choice between inconsistencies.=0A=
=0A=
  I would find it inconsistent to use the Spl naming scheme both for classe=
s with extremely old design decisions=0A=
  from php 5.3 made because they were easy to implement (non-final, linked =
lists, custom iteration behaviors, Iterator instead of `IteratorAggregate`,=
=0A=
  memory inefficiencies), etc with the new objects.=0A=
=0A=
  It'd also be inconsistent to have two different sections in the PHP manua=
l for datastructures because of a constraint on the folder `ext/spl`.=0A=
  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` =
=0A=
  would be another option.=0A=
- Right now, SPL is a mix of classes/interfaces/functions prefixed with Spl=
 and those that aren't,=0A=
  if you look at https://www.php.net/manual/en/book.spl.php ,=0A=
  SPL already has data structures such as `ArrayObject` and interfaces that=
 aren't prefixed.=0A=
=0A=
------=0A=
=0A=
Unrelatedly to this proposal,=0A=
I feel like the internals mailing list may end up repeating a lot of small =
namespacing discussions the next time someone=0A=
proposes adding a class to a different module despite the lack of consensus=
, whether or not the RFC passes.=0A=
=0A=
- There haven't been any class addition RFCs=0A=
   to extensions other than SPL in the last 4 months (i.e. after SPL namesp=
acing was brought up)=0A=
   so it's too early to say if that's the case in practice.=0A=
=0A=
My opinion is that this situation may stall or prevent the proposal and add=
ition of future types to PHP's existing modules,=0A=
especially if small namespace policy votes repeatedly get slightly less tha=
n 2/3 approval and keep getting amended and re-proposed for different exist=
ing modules.=0A=
=0A=
For example, if a hypothetical new contributor (John Jorgesson) were to cre=
ate an =0A=
RFC adding "\GMPRational" for fractions with arbitrary-precision numerators=
 and denominators (rational numbers),=0A=
and there (hypothetically) was broad support for adding GMPRational in php-=
src (I'm not proposing adding GMPRational):=0A=
=0A=
Someone who may or may not be involved with implementing GMPRational might =
suggest that that new contributor=0A=
start working on the broader proposal of migrating GMP to use namespaces=0A=
and all of the naming discussion that entails before there's a widely accep=
ted namespacing policy=0A=
(e.g. discussion on moving `GMP` to `GMP\GMP` or `GMP\BigInt` or `PHP\BigIn=
t` or `PHP\GMP\BigInt`), either leading to=0A=
=0A=
1. Adding GMP namespacing changes to the proposal, significantly raising th=
e duration, time and energy involvement =0A=
   beyond what John expected for the original proposal,=0A=
   and John's RFC facing a effectively steeper threshold than to pass becau=
se votes against adding datatypes are mixed with votes against the particul=
ar namespace choice=0A=
   (e.g. potentially setting a bad precedent or being done before namespace=
 policy consensus was made.)=0A=
2. Keeping the proposal in the global namespace and facing a much steeper t=
hreshold to pass because=0A=
   votes against adding datatypes are mixed with votes made on principle ag=
ainst NOT namespacing by voters who otherwise may not have voted on GMP RFC=
s.=0A=
3. John Jorgesson abandoning the RFC process, possibly creating a PECL inst=
ead for something that (hypothetically) should have been in php-src.=0A=
=0A=
Regards,=0A=
Tyson=0A=