Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116108
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Adding `final class Deque` to PHP
Thread-Index: AQHXraUxaK1dZ0niuECOJlLUpHNcpausmdSAgABGlsg=
Date: Mon, 20 Sep 2021 13:46:34 +0000
Message-ID:
 <DM6PR07MB6618BB856E1C9113823AE67CF9A09@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB66185E23B803C5E5BF858B30F9DF9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <2cc07ebd-81b0-6083-3b3d-2a678ba39784@processus.org>
In-Reply-To: <2cc07ebd-81b0-6083-3b3d-2a678ba39784@processus.org>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: d2af86b3-52f4-7ce2-49e2-6c19d2677009
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [Rwwr5zcsFvB0mJ4MtgwIV7tiHROwP/f3a4I43Dg1Vj7CVrjb4uHmQCYaNkLDP7SZ]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 20e16e97-09d4-4899-53f5-08d97c3d0fcf
x-ms-traffictypediagnostic: DM6PR07MB8111:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 44a6ELl2sp3gjfiTtj2eaGYYGXKPBYiBvgomct/Or8eiL2dNRMwWuW/29YP6sYnf4zWUwDWr2rHHCdUOJC+FeY/vh2lAf2Fb1Ymeq9EumgvN23oSfgYhesr+80ShgrOHCNF7DjcPCTw/787Dqa4imq3z5ZptTE6XJs7tjbpV4RBOtwzAZIJmrfiEaT6+SCOerLSCISH2QrcgKJncFbigSsQ+FTeDjIvN1TERVX4N/jMzBYZznL42kH1JJgs53uH6pLI45zIWACq8PfJ4ph65wcsDLna6DsnEP2Sm07Tvgu853Awuo/FjF4rsECgz1DV52xmwZDHEW1jIT0waMXpV5ZcHAnzhtJTk0wNm1RW1kiumo5VuIN9xwSL51vQZzpf80POvWLA/JpM/Hr42xJYoEU9/oGTofaKnbDT/7jib/CLbSUdQpMnuvH93DliMjZ1Q0ZREBnAhcWLsPCLfZUiOxrV/EIGezUF6smYI2dYvi0GRbxHkwOoKnqwwF6akr0W5s0tTZTKuxnRjcPZFY2pdEw==
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 OqcwL9kacD0zDzTkAe8OGBGGL5frKqrhNowwnkwQobCoBgVjuu5LxAICNqaePh+1eWyfVEeU1cPN0s/MsoHcilCOxmRyyAd0flnFmSkQARMU0RPbCnxtxGztdFNKSxDyacWVEnfzcSAnBHzhnO5eo3Qu+QpGHhG07qtt9b/i5L+eX6Ib/qvXrPrHhbU5Abm0w2b7/NQATEDVFpUvgVjrLw==
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: sct-15-20-3174-20-msonline-outlook-35401.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR07MB6618.namprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 20e16e97-09d4-4899-53f5-08d97c3d0fcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2021 13:46:34.9321
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
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: DM6PR07MB8111
Subject: Re: [PHP-DEV] Adding `final class Deque` to PHP
From: tysonandre775@hotmail.com (tyson andre)

Hi Pierre,=0A=
=0A=
> It seems that you are writing more than one RFC to add many data =0A=
> structures. I love that you're doing that, but I suggest that you'd =0A=
> normalize them all=0A=
=0A=
I'm not certain what you mean by "normalize".=0A=
https://www.merriam-webster.com/dictionary/normalize mentions=0A=
=0A=
1. "to make conform to or reduce to a norm or standard"=0A=
2. https://www.freetext.org/Introduction_to_Linear_Algebra/Basic_Vector_Ope=
rations/Normalization/=0A=
   (no pun intended)=0A=
3. "to bring or restore to a normal condition"=0A=
=0A=
If you mean to make Vector and Queue's APIs consistent with each other,=0A=
I plan to make changes to Vector (e.g. remove $preserveKeys, add isEmpty), =
but the Vector RFC is currently on hold.=0A=
=0A=
If you also mean all datastructure RFCs should be combined into a single RF=
C,=0A=
I'd considered combining the Vector RFC with https://wiki.php.net/rfc/deque=
,=0A=
but decided against combining the RFCs in this instance, because of:=0A=
=0A=
1. Current discussion about whether or not to choose an alternate name for =
a `Vector`=0A=
2. The fact that `Deque` has much better performance for various queue work=
loads=0A=
   on both time and memory usage than `array`=0A=
   (and significantly better performance than `SplDoublyLinkedList`).=0A=
=0A=
Still, I may consider the approach for future RFCs, given that=0A=
=0A=
1. Many developers in internals have expressed a desire for having a signif=
icantly =0A=
   larger data structure library in core along the lines of what php-ds pro=
vides,=0A=
   but may be uninterested in some of the individual datastructures or desi=
gn choices.=0A=
=0A=
   E.g. if 60% of developers were in favor of a sorted set and its proposed=
 API/name =0A=
   (along the lines of https://cplusplus.com/reference/set/set/),=0A=
   60% were in favor of an immutable sequence and its proposed API/name (of=
 values) (similar to https://docs.python.org/3/tutorial/datastructures.html=
#tuples-and-sequences),=0A=
   then with the 2/3 voting threshold,=0A=
   neither of those RFCs would pass but a proposal combining those two woul=
d pass,=0A=
   despite ~95% of developers wanting some type of improved datastructures =
added to core in general (I would guess).=0A=
2. This would allow seeing how datastructures compare to each other.=0A=
=0A=
Combining RFCs has the drawback of significantly increasing the implementat=
ion, discussion, review,=0A=
delays, and time involvement for the volunteer RFC authors and voters,=0A=
and may lead to a larger number of last-minute concerns raised after voting=
 has started when more time =0A=
is spent trying out the new code and looking at the RFC.=0A=
=0A=
> and place all new classes in a single new dedicated =0A=
> namespace.=0A=
=0A=
My rationale for deciding against a dedicated namespace is in https://wiki.=
php.net/rfc/deque#global_namespace=0A=
which I've recently expanded on.=0A=
=0A=
The `Deque` proposal is normalized with respect to the namespace choice of =
data structures that already exist.=0A=
=0A=
The choice of global namespace maintains consistency with the namespace use=
d for general-purpose collections already in the SPL =0A=
(as well as relatively recent additions such as ''WeakReference'' (PHP 7.4)=
 and ''WeakMap'' (PHP 8.0)).=0A=
Other recent additions to PHP such as ''ReflectionIntersectionType'' in PHP=
 8.1 have =0A=
also continued to use the global namespace when adding classes with functio=
nality related to other classes.=0A=
=0A=
Additionally, prior polls for namespacing choices of other datastructure fu=
nctionality showed preferences =0A=
for namespacing and not namespacing were evenly split in a straw poll for a=
 new iterable type=0A=
(https://wiki.php.net/rfc/cachediterable_straw_poll#namespace_choices)=0A=
=0A=
Introducing a new namespace for data structures would also raise the questi=
on of whether existing datastructures =0A=
should be moved to that new namespace (for consistency), and that process w=
ould:=0A=
=0A=
1. Raise the amount of work needed for end users or library/framework/appli=
cation authors to migrate to new PHP versions.=0A=
2. Cause confusion and inconvenience for years about which namespace can or=
 should be used in an application =0A=
   (''SplObjectStorage'' vs ''Xyz\SplObjectStorage''), especially for devel=
opers working on projects supporting different php version ranges.=0A=
3. Prevent applications/libraries from easily supporting as wide of a range=
 of php versions as they otherwise could.=0A=
4. Cause serialization/unserialization issues when migrating to different p=
hp versions,=0A=
   if the old or new class name in the serialized data did not exist in the=
 other php version and was not aliased.=0A=
   For example, if the older PHP version could not ''unserialize()'' ''Xyz\=
SplObjectStorage'' =0A=
   and would silently create a `__PHP_Incomplete_Class_Name` =0A=
   (see https://www.php.net/manual/en/language.oop5.serialization.php#langu=
age.oop5.serialization)=0A=
   without any warnings or notices.=0A=
=0A=
Thanks,=0A=
Tyson=0A=