Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123890
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: <8498ecf7-f431-4d68-aaf1-dc4cfb00241b@app.fastmail.com>
In-Reply-To: <d9711524-6818-4148-873a-4f27c32a270e@varteg.nz>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <CAG4FTXz6cH26C5H51VmTGnpFK5XxROFbW4yDzwAw2v1gcQWGgA@mail.gmail.com>
 <CAPzBOBOTSCCKDR4pDocr4xW+oEXJ27YizgPLkn1PGR9nyPU7ww@mail.gmail.com>
 <1E295280-619B-4490-B53C-0899B64F9215@chaz.works>
 <CAPzBOBPSSEmEbPj1zLcfGOOG7voo7YMUO16NjXzpTy7Wfx4ycw@mail.gmail.com>
 <CAPyj-LAM7yPZpcArjHYEG8HhNRR-hA8sgzAjXT7Wf8X4mVgmQA@mail.gmail.com>
 <97a93ae2-5202-47eb-bf51-ec1e976ea765@app.fastmail.com>
 <CAPyj-LC49o=RVXigTrHte8EWSmwxPKqT4tyRGWpGf022PDCk8Q@mail.gmail.com>
 <c72033aa-7d55-4560-95ac-6c81c21cdc43@app.fastmail.com>
 <78D0FFF7-3867-4D71-B0C0-FA23E5121C39@rwec.co.uk>
 <10390963-0c2c-441a-bcce-20a0433948c5@app.fastmail.com>
 <d9711524-6818-4148-873a-4f27c32a270e@varteg.nz>
Date: Wed, 26 Jun 2024 22:25:50 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: multipart/alternative;
 boundary=802228c53fd7460ba12154fd9f20d273
From: rob@bottled.codes ("Rob Landers")

--802228c53fd7460ba12154fd9f20d273
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 26, 2024, at 21:50, Morgan wrote:
> On 2024-06-26 09:58, Rob Landers wrote:
> > On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
> >>
> >>
> >> It may be questionable to give meaning to the difference in some of=20
> >> these cases, but different it definitely is.
> >=20
> > True, but I was mainly referring to what you would do after performi=
ng=20
> > an 'is', in which case, you probably wouldn't be using any of those=20
> > functions, or if you needed to, then why do you need 'is'? Even with=
 the
> >=20
> > $hasFoo =3D $arr is [?'foo' =3D> string];
> >=20
> > You still have to run array_key_exists() to determine whether the ke=
y=20
> > exists, which means you likely still need to figure out a default va=
lue,=20
> > and null-coalesce is perfect for that ... but then it just points ou=
t=20
> > that it isn't that useful of a check, and that it is inconsistent wi=
th=20
> > itself.
> >=20
> So the issue has nothing to do with this hypothetical infinity of=20
> unobservable nulls, and comes entirely down to the fact that with this=20
> pattern a variable may pass
> a) because it does not have a key named 'foo', or
> b) because it has a key named 'foo' with a string value.

I think this will be my last email on the subject because it=E2=80=99s l=
ike talking to a brick wall.=20

There=E2=80=99s nothing hypothetical about it.=20

while(true) var_dump([][random_int()]);

>=20
> In other words, "this key is optional, but if it is defined it must=20
> match this pattern".

Seriously, write out using it both ways. I asked in the beginning for so=
meone to give a realistic example showing a practical difference in the =
final implementation and I haven=E2=80=99t seen one. I will gracefully e=
at my hat. The main issue is that key-existence-check is logically incon=
sistent with itself (if you say the key shouldn=E2=80=99t exist or be a =
string, you=E2=80=99d be surprised to get null from that key!)

And with that, I bid adieu to this topic.=20

>=20
> On its lonesome, that doesn't look very useful, but I expect it would =
be=20
> one component of a larger pattern (such as "['bar' =3D> string, ?'foo'=
 =3D>=20
> string, ...]"). Rather than (near-)duplicate blocks for "it does not=20
> have the key" and "it has the key and it holds a string", there can be=20
> one block (which might or might not care about the distinction).
>=20

=E2=80=94 Rob
--802228c53fd7460ba12154fd9f20d273
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}</style></head><body><div>On Wed, Jun 26,=
 2024, at 21:50, Morgan wrote:<br></div><blockquote type=3D"cite" id=3D"=
qt" style=3D""><div>On 2024-06-26 09:58, Rob Landers wrote:<br></div><di=
v>&gt; On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:<br><=
/div><div>&gt;&gt;<br></div><div>&gt;&gt;<br></div><div>&gt;&gt; It may =
be questionable to give meaning to the difference in some of&nbsp;<br></=
div><div>&gt;&gt; these cases, but different it definitely is.<br></div>=
<div>&gt;&nbsp;<br></div><div>&gt; True, but I was mainly referring to w=
hat you would do after performing&nbsp;<br></div><div>&gt; an 'is', in w=
hich case, you probably wouldn't be using any of those&nbsp;<br></div><d=
iv>&gt; functions, or if you needed to, then why do you need 'is'? Even =
with the<br></div><div>&gt;&nbsp;<br></div><div>&gt; $hasFoo =3D $arr is=
 [?'foo' =3D&gt; string];<br></div><div>&gt;&nbsp;<br></div><div>&gt; Yo=
u still have to run array_key_exists() to determine whether the key&nbsp=
;<br></div><div>&gt; exists, which means you likely still need to figure=
 out a default value,&nbsp;<br></div><div>&gt; and null-coalesce is perf=
ect for that ... but then it just points out&nbsp;<br></div><div>&gt; th=
at it isn't that useful of a check, and that it is inconsistent with&nbs=
p;<br></div><div>&gt; itself.<br></div><div>&gt;&nbsp;<br></div><div>So =
the issue has nothing to do with this hypothetical infinity of&nbsp;<br>=
</div><div>unobservable nulls, and comes entirely down to the fact that =
with this&nbsp;<br></div><div>pattern a variable may pass<br></div><div>=
a) because it does not have a key named 'foo', or<br></div><div>b) becau=
se it has a key named 'foo' with a string value.<br></div></blockquote><=
div><br></div><div>I think this will be my last email on the subject bec=
ause it=E2=80=99s like talking to a brick wall.&nbsp;<br></div><div><br>=
</div><div>There=E2=80=99s nothing hypothetical about it.&nbsp;<br></div=
><div><br></div><div>while(true) var_dump([][random_int()]);<br></div><d=
iv><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></d=
iv><div>In other words, "this key is optional, but if it is defined it m=
ust&nbsp;<br></div><div>match this pattern".<br></div></blockquote><div>=
<br></div><div>Seriously, write out using it both ways. I asked in the b=
eginning for someone to give a realistic example showing a practical dif=
ference in the final implementation and I haven=E2=80=99t seen one. I wi=
ll gracefully eat my hat. The main issue is that key-existence-check is =
logically inconsistent with itself (if you say the key shouldn=E2=80=99t=
 exist or be a string, you=E2=80=99d be surprised to get null from that =
key!)<br></div><div><br></div><div>And with that, I bid adieu to this to=
pic.&nbsp;<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" s=
tyle=3D""><div><br></div><div>On its lonesome, that doesn't look very us=
eful, but I expect it would be&nbsp;<br></div><div>one component of a la=
rger pattern (such as "['bar' =3D&gt; string, ?'foo' =3D&gt;&nbsp;<br></=
div><div>string, ...]"). Rather than (near-)duplicate blocks for "it doe=
s not&nbsp;<br></div><div>have the key" and "it has the key and it holds=
 a string", there can be&nbsp;<br></div><div>one block (which might or m=
ight not care about the distinction).<br></div><div><br></div></blockquo=
te><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body=
></html>
--802228c53fd7460ba12154fd9f20d273--