Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116091
To: php internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] RFC: Add `final class Vector` to PHP
Thread-Index: AQHXq2Dr5ROExEhu802SAlX6zd1M+6uosVGAgABRo6CAAPOxgIAAA0Mu
Date: Sat, 18 Sep 2021 16:58:19 +0000
Message-ID:
 <DM6PR07MB66180932CFAEC8A103B05E5DF9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <DM6PR07MB6618D41DE7680BE2BE8086DAF9DD9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <b51e40d2-0e31-4b28-ba7d-0237ed831bde@www.fastmail.com>
 <DM6PR07MB661871FD349540EB1CEECF35F9DE9@DM6PR07MB6618.namprd07.prod.outlook.com>
 <29eb9519-ab67-44b2-9d62-9c591715946a@www.fastmail.com>
In-Reply-To: <29eb9519-ab67-44b2-9d62-9c591715946a@www.fastmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
suggested_attachment_session_id: c5203d39-9e6e-8098-3fc7-c3e901700a83
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn:
 [OG3xPB1n4NmSTnE6NYIkuakGK3dRnS5p8YyPhMHoMtYAY578gHESnfNR20aLnzzvF1rZz/TBI8I=]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d44cea48-2d66-4096-e25e-08d97ac583ff
x-ms-traffictypediagnostic: DM6PR07MB6122:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 0Onioo3nMNzZzOzbUSo4GPhVvIwvijtGH+hFXSNydMvp2B8k64AXQhqAAEStTkPMPER0EUwg0HpIjw5fUHFVTDPQQfyV6ti6ufksEmweKgwqigIGw2rQuUqZi3UJ5nAJpKzr/eBslOYxhouko8zzNLOWLKPLGVxCwq3ImyDtnyoJKLEUCG6FKypL/DxviXujFq5k8Fuy6QVL9x1hVJkAzBWQVIfQ//0U4Wgy288rykRmXQ4Dvc9TnIQS3izxk9ZZOFnmSOw3rLEX8pbV0r/2s8OZ7U3RcQE5sXJTuAPr1Y4DIQHZM0OmlO+p/b04QY6Dn6kIA8tvdf6Bh3p2ncm4ZO2JcNkjoEvK0Eq8hcQ6zsrp8oiebs+r+cG8KezTxRNyHO/XKSJQgDiLX+82NboM+tLJ4jUfV0SjZLPy7an8U5IoGcqM3jDJRxK/qpvGitHGkzEEFCdBeLq0QwnBsguT3FIEvpSA93yR2/s8/9BRLoE=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 f+MmMS5uxFFZ1qw8+VHfXYDuZw8izlf5HsLsnao8bL1P+hqKfAzHk/OIRVuUknPmDv8dfuyZpPT5ysoqQBwfQj83/eJQnMjAyQ84ZUu9Wb4dpxHekYptCcG0gNXZccxFvYwdDPGhE3wvvK+gL1hqkueCRHekWPXhvXG3ix0l8ggAbnPZm4I1lJ0dNWMt3RkjHkUAZgr1QuLHHqbQ8eJmBQ==
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: d44cea48-2d66-4096-e25e-08d97ac583ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2021 16:58:19.0897
 (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: DM6PR07MB6122
Subject: Re: [PHP-DEV] RFC: Add `final class Vector` to PHP
From: tysonandre775@hotmail.com (tyson andre)

Hi Larry Garfield,=0A=
=0A=
> Rather than go point by point, I'm going to respond globally here.=0A=
> =0A=
> I am frequently on-record hating on PHP arrays, and stating that I want s=
omething better.=A0 The problems with PHP arrays include:=0A=
> =0A=
> 1. They're badly performing (because they cannot be optimized)=0A=
> 2. They're not type safe=0A=
> 3. They're mutable=0A=
> 4. They mix sequences (true arrays) with dictionaries/hashmaps, making ev=
erything uglier=0A=
> 5. People keep using them as structs, when they're not=0A=
> 6. The API around them is procedural, inconsistent, and overall gross=0A=
> 7. They lack a lot of native shorthand operations found in other language=
s (eg, slicing)=0A=
> 8. Their error handling is crap=0A=
> =0A=
> Any new native/stdlib alternative to arrays needs to address at least hal=
f of those issues, preferably most/all.=0A=
> =0A=
> This proposal addresses the first point and... that's it.=A0 Point 5 is s=
ort of covered by virtue of being out of scope, so maybe this covers 1.5 ou=
t of 8.=A0 That's insufficient to be worth the effort to support and deal w=
ith in code.=A0 That makes this approach a strong -1 for me.=0A=
> =0A=
> "Fancy algorithms are slow when n is small, and n is usually small." -- R=
ob Pike=0A=
> =0A=
> That some of the design choices here mirror existing poor implementations=
 is not an endorsement of them.=A0 I don't think I've seen anyone on this l=
ist say anything good about SPL beyond iterators and autoloading, so it's n=
ot really a good model to emulate.=0A=
> =0A=
> Additionally, please don't play into the trope about procedural/mutable c=
ode being more beginner friendly.=A0 That's not the case, beyond being a se=
lf-fulfilling prophesy.=A0 (If we teach procedural/mutable code first, then=
 most beginners will be most proficient in procedural/mutable code.)=A0 I w=
ould argue that, on the whole, immutable values make code easier to reason =
about and write once you get past trivially small sizes.=A0 We do new devel=
opers a gross disservice by treating immutability as an "advanced" techniqu=
e, when it should really be the default, beginner technique taught from day=
 one.=0A=
> =0A=
> I am not aware of any PECL implementations of lists that have type safety=
, because I don't use many PECL packages.=A0 However, in user space it's qu=
ite simple to do:=0A=
> =0A=
> https://presentations.garfieldtech.com/slides-never-use-arrays/phpkonf202=
1/#/5/2=0A=
> =0A=
> See that slide and scroll down for additional examples.=A0 Every one of t=
hose examples took me less than 5 minutes to write.=A0 If we want to have a=
 better alternative in core, it needs to be *at least* as capable as what I=
 can throw together in 5 minutes.=A0 The proposal as-is is not even as capa=
ble as those examples.=0A=
=0A=
Yes, you can implement those immutable and typed data structures in userlan=
d.=0A=
You are doing that by adding userland code hiding the internal implementati=
ons of the mutable `array` to solve the needs of your library/application (=
e.g. those 8).=0A=
Adding a mutable `Vector` gives another way to internally represent those u=
serland data structures when you need those userland data structures to sha=
re data internally without using PHP references (not as part of the public =
api), e.g. appending to a list of error objects, performing a depth-first s=
earch or breadth-first search, etc.=0A=
=0A=
As for your example, it's impossible to type hint without generics, and nob=
ody's working on generics.=0A=
If I have your userland `TypedArray::forType(MyClass::class);`,=0A=
I can pass it to any parameter/return value/property expecting a `TypedArra=
y`,=0A=
but that will then throw an Error at runtime with no warning ahead of time =
if I pass it to a function expecting a `TypedArray` of `OtherClass`.=0A=
Static analyzers exist separately from php that could analyze that, but =0A=
=0A=
1. Many developers wouldn't have static analyzers set up.=0A=
2. The TypedArrays may be created from unserialization from apcu/memcache/r=
edis and be impractical to analyze (e.g. from an older release of a library=
 or application)=0A=
3. Voters may object to this additional way to write PHP code that could er=
ror at runtime.=0A=
=0A=
**What data structures do you want in core? Do you want them to eagerly eva=
luate generators or lazily evaluate them? Is `TypedArray` or `TypedSequence=
` something you think should have an RFC or plan to create an RFC for?**=0A=
=0A=
Even if immutable data structures are proposed, there's a further division =
between programmers who want lazy or eager immutables (e.g. their construct=
ors or factory methods to eagerly evaluate iterable values or lazily evalua=
te values),=0A=
and there may be enough objections to either choice (for the specific data =
structure proposed) when it was time to actually vote to result in the vote=
 failing.=0A=
(in addition to other objections that come up in any new proposal for core =
datastructures)=0A=
This discourages me from proposing immutable data structures.=0A=
=0A=
I'd agree on the utility of Set/Map/sorted data structures (though the hash=
able vs not hashable, comparator vs no comparator, how to hash, etc. is a d=
iscussion that I believe would be time consuming and hasn't happened yet).=
=0A=
Because PHP has no stack overflow/recursion depth detection and just segfau=
lts at runtime, I believe strict `=3D=3D=3D` equality like that example=0A=
and like JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript=
/Reference/Global_Objects/Map would be the most appropriate for an proposal=
 made long after PHP was released.=0A=
But while I'm open to adding immutable data structures, the mutable datastr=
uctures should also exist in many cases, and I believe immutable should be =
named or namespaced that way.=0A=
=0A=
Thanks,=0A=
Tyson=0A=