Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130582
Precedence: list
MIME-Version: 1.0
References: <CABVsipg7tPv8roLP4CpJRBeK_beds-R-_DE7DXKnznZsd5UbiQ@mail.gmail.com>
 <1775385960072.803756451.2349920337@yahoo.de> <CABVsipjSVt0G5cujdYXM-vmDNuYQs2xstJ0sa4CHcLZWWocoeA@mail.gmail.com>
 <1b1eb4f5-4701-4ccb-94b7-42306c3f33b5@app.fastmail.com>
In-Reply-To: <1b1eb4f5-4701-4ccb-94b7-42306c3f33b5@app.fastmail.com>
Date: Mon, 6 Apr 2026 18:21:20 +0200
Message-ID: <CABVsipiyd81s1Do_HEJKR4fsU+BXAjnH2qickjX8o0-=exH0ag@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003f2d07064ecd0f62"
From: barel.barelon@gmail.com (Barel)

--0000000000003f2d07064ecd0f62
Content-Type: text/plain; charset="UTF-8"

On Mon, 6 Apr 2026 at 18:12, Larry Garfield <larry@garfieldtech.com> wrote:

> On Mon, Apr 6, 2026, at 10:01 AM, Barel wrote:
> > Following some comments from some users I have decided to also allow
> > the $key parameter to be a list of strings/ints so that this
> > functionality can also be used without using dot notation. I believe
> > this also removes the need to add any kind of dot escaping. If your
> > segments can contain dots, just use the form of the function that
> > accepts an array.
> >
> > It was suggested that accepting an iterable would be a good addition
> > but none of the array_ functions accept an iterable so I don't think it
> > would be good to make an exception here
> >
> > The proposed implementation in GitHub has also been updated with this
> change
> >
> > Cheers
> >
> > Carlos
>
> Please remember to bottom post. :-)
>
> It looks like the RFC hasn't been fully updated for array-based "keys"
> yet.  The function signatures in most of the examples still say
> string|int|null.
>
> Despite my long-standing and public crusade against arrays being used
> where an object belongs, I'm overall in favor of this direction.  However,
> I would go all-in on the array syntax, not the dotted syntax.  There's a
> few reasons for that.
>
> 1. The various notes around escaping.  Having a string instruction format
> that doesn't handle escaping and encoding and other edge cases is asking
> for trouble, and it's trouble that will be harder to fix in the future.
> String instructions are always more complicated and nuanced than you
> expect, so a simple "split on the dot and now it's an array!" approach is
> just too rudimentary to be trustworthy, for all the reasons mentioned in
> previous posts.
>
> 2. If you're not building the path dynamically, then there is little
> advantage of it over what we have now.
>
> array_get($array, 'foo.bar.1.baz', null);
>
> $array['foo']['bar'][1]['baz'] ?? null
>
> The second may be slightly slower to type because of the punctuation, but
> it's perfectly viable today.
>
> Where it becomes interesting is when the path is variable... and if the
> path is variable, I'll probably want to be building it dynamically rather
> than just selecting one of a few hard-coded options.  And if I'm building
> it dynamically, then string concatenation is an awful way to do that, for
> all the escaping reasons mentioned previously.  We're back to concatenating
> SQL strings together, with all the risk that entails.
>
> So I would be in favor of going all the way to
>
> function array_get(array $array, array $path, mixed $default = null) {}
>
> Or, for that matter, that is nearly the same as:
>
> function array_get(array $array, array $path) {}
>
> array_get($arr, $path) ?? null;
>
> Which would allow using a variadic for the $path if desired, instead of an
> array.  I'm not certain that's optimal, but I think it's worth discussing.
> array_has() would then follow suit.
>
> Then, separately, I would be in favor of a full-on JSON Pointer
> implementation that can work on both arrays and JSON blobs, potentially (as
> the two are effectively isomorphic).  Skip a custom dot notation.  Go
> straight to the fully robust standard.  Do not pass go, do not collect 200
> security reports.
>
> --Larry Garfield
>

Larry,

Thanks for pointing out that I had not updated the example code to include
array in the type, this has now been updated

You raise some interesting points in your message. I would like to hear
what other people think about them

Cheers

Carlos

--0000000000003f2d07064ecd0f62
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 6 Apr 2=
026 at 18:12, Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">=
larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">On Mon, Apr 6, 2026, at 10:01 AM, Barel wrote:<br>
&gt; Following some comments from some users I have decided to also allow <=
br>
&gt; the $key parameter to be a list of strings/ints so that this <br>
&gt; functionality can also be used without using dot notation. I believe <=
br>
&gt; this also removes the need to add any kind of dot escaping. If your <b=
r>
&gt; segments can contain dots, just use the form of the function that <br>
&gt; accepts an array.<br>
&gt;<br>
&gt; It was suggested that accepting an iterable would be a good addition <=
br>
&gt; but none of the array_ functions accept an iterable so I don&#39;t thi=
nk it <br>
&gt; would be good to make an exception here<br>
&gt;<br>
&gt; The proposed implementation in GitHub has also been updated with this =
change<br>
&gt;<br>
&gt; Cheers<br>
&gt;<br>
&gt; Carlos<br>
<br>
Please remember to bottom post. :-)<br>
<br>
It looks like the RFC hasn&#39;t been fully updated for array-based &quot;k=
eys&quot; yet.=C2=A0 The function signatures in most of the examples still =
say string|int|null.<br>
<br>
Despite my long-standing and public crusade against arrays being used where=
 an object belongs, I&#39;m overall in favor of this direction.=C2=A0 Howev=
er, I would go all-in on the array syntax, not the dotted syntax.=C2=A0 The=
re&#39;s a few reasons for that.<br>
<br>
1. The various notes around escaping.=C2=A0 Having a string instruction for=
mat that doesn&#39;t handle escaping and encoding and other edge cases is a=
sking for trouble, and it&#39;s trouble that will be harder to fix in the f=
uture.=C2=A0 String instructions are always more complicated and nuanced th=
an you expect, so a simple &quot;split on the dot and now it&#39;s an array=
!&quot; approach is just too rudimentary to be trustworthy, for all the rea=
sons mentioned in previous posts.<br>
<br>
2. If you&#39;re not building the path dynamically, then there is little ad=
vantage of it over what we have now.<br>
<br>
array_get($array, &#39;foo.bar.1.baz&#39;, null);<br>
<br>
$array[&#39;foo&#39;][&#39;bar&#39;][1][&#39;baz&#39;] ?? null<br>
<br>
The second may be slightly slower to type because of the punctuation, but i=
t&#39;s perfectly viable today.<br>
<br>
Where it becomes interesting is when the path is variable... and if the pat=
h is variable, I&#39;ll probably want to be building it dynamically rather =
than just selecting one of a few hard-coded options.=C2=A0 And if I&#39;m b=
uilding it dynamically, then string concatenation is an awful way to do tha=
t, for all the escaping reasons mentioned previously.=C2=A0 We&#39;re back =
to concatenating SQL strings together, with all the risk that entails.<br>
<br>
So I would be in favor of going all the way to <br>
<br>
function array_get(array $array, array $path, mixed $default =3D null) {}<b=
r>
<br>
Or, for that matter, that is nearly the same as:<br>
<br>
function array_get(array $array, array $path) {}<br>
<br>
array_get($arr, $path) ?? null;<br>
<br>
Which would allow using a variadic for the $path if desired, instead of an =
array.=C2=A0 I&#39;m not certain that&#39;s optimal, but I think it&#39;s w=
orth discussing.=C2=A0 array_has() would then follow suit.<br>
<br>
Then, separately, I would be in favor of a full-on JSON Pointer implementat=
ion that can work on both arrays and JSON blobs, potentially (as the two ar=
e effectively isomorphic).=C2=A0 Skip a custom dot notation.=C2=A0 Go strai=
ght to the fully robust standard.=C2=A0 Do not pass go, do not collect 200 =
security reports.<br>
<br>
--Larry Garfield<br></blockquote><div><br></div><div>Larry,</div><div><br><=
/div><div>Thanks for pointing out that I had not updated the example code t=
o include array in the type, this has now been updated<br><br>You raise som=
e interesting points in your message. I would like to hear what other peopl=
e think about them</div><div><br></div><div>Cheers<br><br>Carlos=C2=A0</div=
></div></div>

--0000000000003f2d07064ecd0f62--