Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123849
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: <10390963-0c2c-441a-bcce-20a0433948c5@app.fastmail.com>
In-Reply-To: <78D0FFF7-3867-4D71-B0C0-FA23E5121C39@rwec.co.uk>
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>
Date: Tue, 25 Jun 2024 23:58:26 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
Content-Type: multipart/alternative;
 boundary=6cecdcee61174999bb83452431385b21
From: rob@bottled.codes ("Rob Landers")

--6cecdcee61174999bb83452431385b21
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 25 June 2024 21:24:32 BST, Rob Landers <rob@bottled.codes> wrote:
> >The only way you=E2=80=99d observe this (that I can think of) is by p=
erforming a for-each loop over the array.=20
>=20
> There are many ways you can observe the difference between an absent k=
ey and a null value; here are just a handful off the top of my head:=20
>=20
> - array_key_exists() (that's literally its purpose!)
> - array_keys()
> - count() (if the array held "an infinite number of nulls", we should =
return infinity for every array!)
> - json_encode()
> - print_r(), var_dump(), var_export()
> - extract()
>=20
> It may be questionable to give meaning to the difference in some of th=
ese cases, but different it definitely is.=20

True, but I was mainly referring to what you would do after performing a=
n 'is', in which case, you probably wouldn't be using any of those funct=
ions, or if you needed to, then why do you need 'is'? Even with the=20

$hasFoo =3D $arr is [?'foo' =3D> string];

You still have to run array_key_exists() to determine whether the key ex=
ists, which means you likely still need to figure out a default value, a=
nd null-coalesce is perfect for that ... but then it just points out tha=
t it isn't that useful of a check, and that it is inconsistent with itse=
lf.

If you are running array_keys(), then why bother performing an 'is' when=
 you should already know the structure=E2=80=94that's the entire point o=
f it. If you are running a count(), this kind of goes back to the same t=
hing, but I would think count() would be run on a collection of data rat=
her than structured data.

For json_encode, I could see something like this being a "final check" o=
f some sort, but most people are likely json_encoding objects these days=
. This might be a good use case for this syntax, but I feel like this is=
 the wrong way to solve the problem.

print_r, var_dump, etc. are more or less debugging tools. At least, I've=
 never seen their output used for program execution. I could be wrong.

extract() can go get crushed by an RFC :) but it does occasionally have =
its usefulness. Even then, until PHP 9, an undefined variable will still=
 be null.

>=20
>=20
> > If we don't like it, we can always create an RFC to treat non-existe=
nt keys as an error instead of a warning.
>=20
> I believe that is the explicit intention or desire of those who raised=
 it from Notice to Warning. It would certainly prevent some bugs where a=
 typo leads to the wrong key being accessed.
>=20
> Personally, I'd like to see a few use cases catered for first, like $c=
ounters[$key]++ and $groups[$key][] =3D $value; Perhaps by introducing s=
ome equivalent of Python's "defaultdict". Because I do agree that the cu=
rrent behaviour is useful sometimes (even if I disagree in how to descri=
be it).

I think arrays have their uses, but I'd rather see some purpose-built da=
ta structures where you can fully take advantage of their performance pr=
operties=E2=80=94things like linked lists, heaps, etc. Yeah, there's SPL=
, but its interfaces are kind of a mess since you can use a queue like a=
 deque or a stack (which is just weird and might or might not have perfo=
rmance implications), for example.

>=20
>=20
> Regards,
> Rowan Tommins
> [IMSoP]
>=20

=E2=80=94 Rob
--6cecdcee61174999bb83452431385b21
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 Tue, Jun 25,=
 2024, at 23:10, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 25 Jun=
e 2024 21:24:32 BST, Rob Landers &lt;<a href=3D"mailto:rob@bottled.codes=
">rob@bottled.codes</a>&gt; wrote:<br></div><div>&gt;The only way you=E2=
=80=99d observe this (that I can think of) is by performing a for-each l=
oop over the array.&nbsp;<br></div><div><br></div><div>There are many wa=
ys you can observe the difference between an absent key and a null value=
; here are just a handful off the top of my head:&nbsp;<br></div><div><b=
r></div><div>- array_key_exists() (that's literally its purpose!)<br></d=
iv><div>- array_keys()<br></div><div>- count() (if the array held "an in=
finite number of nulls", we should return infinity for every array!)<br>=
</div><div>- json_encode()<br></div><div>- print_r(), var_dump(), var_ex=
port()<br></div><div>- extract()<br></div><div><br></div><div>It may be =
questionable to give meaning to the difference in some of these cases, b=
ut different it definitely is.&nbsp;<br></div></blockquote><div><br></di=
v><div>True, but I was mainly referring to what you would do after perfo=
rming an 'is', in which case, you probably wouldn't be using any of thos=
e functions, or if you needed to, then why do you need 'is'? Even with t=
he&nbsp;<br></div><div><br></div><div>$hasFoo =3D $arr is [?'foo' =3D&gt=
; string];<br></div><div><br></div><div>You still have to run array_key_=
exists() to determine whether the key exists, which means you likely sti=
ll need to figure out a default value, and null-coalesce is perfect for =
that ... but then it just points out that it isn't that useful of a chec=
k, and that it is inconsistent with itself.</div><div><br></div><div>If =
you are running array_keys(), then why bother performing an 'is' when yo=
u should already know the structure=E2=80=94that's the entire point of i=
t. If you are running a count(), this kind of goes back to the same thin=
g, but I would think count() would be run on a collection of data rather=
 than structured data.<br></div><div><br></div><div>For json_encode, I c=
ould see something like this being a "final check" of some sort, but mos=
t people are likely json_encoding objects these days. This might be a go=
od use case for this syntax, but I feel like this is the wrong way to so=
lve the problem.<br></div><div><br></div><div>print_r, var_dump, etc. ar=
e more or less debugging tools. At least, I've never seen their output u=
sed for program execution. I could be wrong.<br></div><div><br></div><di=
v>extract() can go get crushed by an RFC :) but it does occasionally hav=
e its usefulness. Even then, until PHP 9, an undefined variable will sti=
ll be null.<br></div><div><br></div><blockquote type=3D"cite" id=3D"qt" =
style=3D""><div><br></div><div><br></div><div>&gt; If we don't like it, =
we can always create an RFC to treat non-existent keys as an error inste=
ad of a warning.<br></div><div><br></div><div>I believe that is the expl=
icit intention or desire of those who raised it from Notice to Warning. =
It would certainly prevent some bugs where a typo leads to the wrong key=
 being accessed.<br></div><div><br></div><div>Personally, I'd like to se=
e a few use cases catered for first, like $counters[$key]++ and $groups[=
$key][] =3D $value; Perhaps by introducing some equivalent of Python's "=
defaultdict". Because I do agree that the current behaviour is useful so=
metimes (even if I disagree in how to describe it).<br></div></blockquot=
e><div><br></div><div>I think arrays have their uses, but I'd rather see=
 some purpose-built data structures where you can fully take advantage o=
f their performance properties=E2=80=94things like linked lists, heaps, =
etc. Yeah, there's SPL, but its interfaces are kind of a mess since you =
can use a queue like a deque or a stack (which is just weird and might o=
r might not have performance implications), for example.</div><div><br><=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>=
<br></div><div>Regards,<br></div><div>Rowan Tommins<br></div><div>[IMSoP=
]<br></div><div><br></div></blockquote><div><br></div><div id=3D"sig1212=
29152">=E2=80=94 Rob<br></div></body></html>
--6cecdcee61174999bb83452431385b21--