Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123879
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <6c4bb476-7d4a-4eec-b300-c1d2fe17c631@app.fastmail.com>
In-Reply-To: <0F7B09EC-C38E-4B49-9137-1FB3EA5231AC@miles.systems>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <d06e5a04-9601-4af4-bdad-4f5e92bc5e18@app.fastmail.com>
 <0F7B09EC-C38E-4B49-9137-1FB3EA5231AC@miles.systems>
Date: Wed, 26 Jun 2024 20:38:57 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: multipart/alternative;
 boundary=7a8e5f34f49d4a15b2aa473de39d66ab
From: rob@bottled.codes ("Rob Landers")

--7a8e5f34f49d4a15b2aa473de39d66ab
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 26, 2024, at 19:57, Richard Miles wrote:
> =E2=80=9CArray-application will also be pushed to future-scope=E2=80=9D
>=20
>=20
> Dang, this is what I was looking forward to the most. Helping set some=
 precedent on this issue, and this is a solid start. I=E2=80=99ve been t=
hinking about what it would look like for strictly typed arrays in PHP f=
or a while now. I think a custom implantation like SqlObjectStorage or S=
plFixedArray could help performance since we now have a fixed list and n=
o need for a hash table, and it may solve some complexity in implementat=
ion. This is slightly off-topic, but if anyone is interested in working =
on a typed arrays initiative, please contact me directly.=20

Just a good ole' circular buffer would be nice for so many things (fiber=
 microwork queues, etc) :)

That being said, you can abuse arrays to get better (or at least the sam=
e) performance of SPL for certain data structures (e.g., priority queues=
/heaps: https://withinboredom.info/2022/09/04/algorithms-in-php-priority=
-queues-and-heaps/ -- the listing isn't complete or fully working, FWIW)=
. Those little arrays have much power, and I love them for some tasks.

>=20
> That said, I agree with Robert Landers, who wrote the following:
>=20
> There's no need to use `?` to check for existence on a key, so this:
>=20
> $arr is ['a' =3D> string, ?'b' =3D> string, ...];
>=20
> should be this:
>=20
> $arr is ['a' =3D> string, 'b' =3D> ?string, =E2=80=A6];
>=20
> ______
>=20
> Chuck Adams cleared that up with:
> The first means b is an optional key, but if it=E2=80=99s there, can o=
nly be a string. The second says b is a required key, but it may be a st=
ring or null. If there were a binding involved, that determines the type=
 of the binding in incompatible ways.
> ______
>=20
> I think there is a need to ensure a key does not exist even if we=E2=80=
=99re not happy about this syntax, but if not having `$arr is ['a' =3D> =
string, 'b' =3D> ?string, =E2=80=A6]` would still make me very happy.=20

The only time I can't think of this being important (whether or not a ke=
y exists) is during serialization/deserialization, where you may want to=
 leave something its default value. In that case, you likely won't know =
what the keys are supposed to be in the first place (thus unable to use =
them in something like "is" or "as"). In the case that you did, this wou=
ld be perfectly reasonable:

$keys =3D array_keys($arr) is [ "a", ?"b", ?"c"];

It's still weird-looking, but it tells you that the keys may or may not =
exist, and it is consistent with itself. However, what if the array is i=
n a different order or missing keys (e.g., ["c", "a"])? You can see how =
this gets complicated pretty quickly. If I am getting hung up on $arr['n=
on-existent-key'] technically being null, you can imagine how someone el=
se -- maybe even me if I thought about it long enough -- would argue tha=
t ["a", ?"b", ?"c"] may or may not match ["a", "c"] as the arguments for=
 either way are pretty strong and the usecases for either way being just=
 as valuable. It's a good call to punt it for deeper discussion later.

>=20
> Best,
>=20
> Richard Miles

Please remember to bottom-post ;)

=E2=80=94 Rob
--7a8e5f34f49d4a15b2aa473de39d66ab
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Ju=
n 26, 2024, at 19:57, Richard Miles wrote:<br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D"overflow-wrap:break-word;"><div>=E2=80=9CArray-=
application will also be pushed to future-scope=E2=80=9D<br></div><div><=
div><br></div><div><br></div><div>Dang, this is what I was looking forwa=
rd to the most. Helping set some precedent on this issue, and this is a =
solid start. I=E2=80=99ve been thinking about what it would look like fo=
r strictly typed arrays in PHP for a while now. I think a custom implant=
ation like SqlObjectStorage or SplFixedArray could help performance sinc=
e we now have a fixed list and no need for a hash table, and it may solv=
e some complexity in implementation. This is slightly off-topic, but if =
anyone is interested in working on a typed arrays initiative, please con=
tact me directly.&nbsp;<br></div></div></blockquote><div><br></div><div>=
Just a good ole' circular buffer would be nice for so many things (fiber=
 microwork queues, etc) :)<br></div><div><br></div><div>That being said,=
 you can abuse arrays to get better (or at least the same) performance o=
f SPL for certain data structures (e.g., priority queues/heaps: https://=
withinboredom.info/2022/09/04/algorithms-in-php-priority-queues-and-heap=
s/ -- the listing isn't complete or fully working, FWIW). Those little a=
rrays have much power, and I love them for some tasks.<br></div><div><br=
></div><blockquote type=3D"cite" id=3D"qt" style=3D"overflow-wrap:break-=
word;"><div><div><br></div><div>That said, I agree with Robert Landers, =
who wrote the following:<br></div><div><br></div><div><div>There's no ne=
ed to use `?` to check for existence on a key, so this:<br></div><div><b=
r></div><div>$arr is ['a' =3D&gt; string, ?'b' =3D&gt; string, ...];<br>=
</div><div><br></div><div>should be this:<br></div><div><br></div><div>$=
arr is ['a' =3D&gt; string, 'b' =3D&gt; ?string, =E2=80=A6];<br></div></=
div><div><br></div><div>______<br></div><div><br></div><div>Chuck Adams =
cleared that up with:<br></div><div>The first means b is an optional key=
, but if it=E2=80=99s there, can only be a string. The second says b is =
a required key, but it may be a string or null. If there were a binding =
involved, that determines the type of the binding in incompatible ways.<=
br></div><div>______<br></div><div><br></div><div>I think there is a nee=
d to ensure a key does not exist even if we=E2=80=99re not happy about t=
his syntax, but if not having `$arr is ['a' =3D&gt; string, 'b' =3D&gt; =
?string, =E2=80=A6]` would still make me very happy.&nbsp;<br></div></di=
v></blockquote><div><br></div><div>The only time I can't think of this b=
eing important (whether or not a key exists) is during serialization/des=
erialization, where you may want to leave something its default value. I=
n that case, you likely won't know what the keys are supposed to be in t=
he first place (thus unable to use them in something like "is" or "as").=
 In the case that you did, this would be perfectly reasonable:<br></div>=
<div><br></div><div>$keys =3D array_keys($arr) is [ "a", ?"b", ?"c"];<br=
></div><div><br></div><div>It's still weird-looking, but it tells you th=
at the keys may or may not exist, and it is consistent with itself. Howe=
ver, what if the array is in a different order or missing keys (e.g., ["=
c", "a"])? You can see how this gets complicated pretty quickly. If I am=
 getting hung up on $arr['non-existent-key'] technically being null, you=
 can imagine how someone else -- maybe even me if I thought about it lon=
g enough -- would argue that ["a", ?"b", ?"c"] may or may not match ["a"=
, "c"] as the arguments for either way are pretty strong and the usecase=
s for either way being just as valuable. It's a good call to punt it for=
 deeper discussion later.<br></div><div><br></div><blockquote type=3D"ci=
te" id=3D"qt" style=3D"overflow-wrap:break-word;"><div><div><div><br></d=
iv><div><div dir=3D"auto" style=3D"font-family:Helvetica;font-size:12px;=
font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacin=
g:normal;text-align:start;text-indent:0px;text-transform:none;text-wrap:=
wrap;word-spacing:0px;-webkit-text-stroke-width:0px;text-decoration-line=
:none;text-decoration-thickness:initial;text-decoration-style:initial;te=
xt-decoration-color:initial;color:rgb(0, 0, 0);overflow-wrap:break-word;=
"><div>Best,<br></div><div><br></div><div>Richard Miles<br></div></div><=
/div></div></div></blockquote><div><br></div><div>Please remember to bot=
tom-post ;)<br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 R=
ob<br></div></body></html>
--7a8e5f34f49d4a15b2aa473de39d66ab--