Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130664
Precedence: list
MIME-Version: 1.0
References: <CABVsipicHroAcWJSEpjwM4+y6p-6axV-6tO__MejThESFVCP3A@mail.gmail.com>
 <CABdc3WrsYzNd=s5LYkpqphVr_PWVEOyDCcZcC9QkzhKUU7r2ow@mail.gmail.com>
 <CABVsipgfS2j49iBm38X8g1N1RdVZfHudaBqBrdNLfTMpUZfC2w@mail.gmail.com>
 <f0a77882-44e2-4cd9-be14-eca9163194ca@app.fastmail.com> <CABVsipjQiay5NK36Rwtwk6tDi0mRwa+Wv4oSz17qR_vwresYfw@mail.gmail.com>
 <19d58a46b50222b75da4e40e417efd05@bastelstu.be>
In-Reply-To: <19d58a46b50222b75da4e40e417efd05@bastelstu.be>
Date: Sat, 18 Apr 2026 08:06:54 +0200
Message-ID: <CABVsiph+=CeAkAL6XwzD57qDPt=24r8sh4HV32BOPmRFXfTqSw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f820ce064fb5df58"
From: barel.barelon@gmail.com (Barel)

--000000000000f820ce064fb5df58
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 15 Apr 2026 at 20:18, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:

> Hi
>
> Am 2026-04-14 19:06, schrieb Barel:
> > - I see the point that Tim made about the function names, I have
> > updated
> > them to array_get_path() and array_has_path()
>
> Similarly to Rob's tongue in cheek comment, I think I would also prefer
> having a common prefix for the functions, since this improves
> discoverability. While there are some inconsistencies in the array API
> due to its age, I think there is a reasonably similar precedent with the
> `array_key_*()` functions. In fact looking at those, I wonder if the
> following pair of names would make sense for your proposed feature:
>
> - array_path()
> - array_path_exists()
>
>  From what I see, the functions in the array API don't mention =E2=80=9Cg=
et=E2=80=9D as
> the default operation, e.g. it's `array_first()`, not
> `array_get_first()`. And for =E2=80=9Cexistence checks=E2=80=9D there's t=
he obvious
> precedent with `array_key_exists()` which is also used in the example
> implementation in your RFC.
>

Tim, thanks again for your comments. I did not like using `array_path._...`
because the function name reads less naturally, but I agree that it
improves discoverability and is more in line with existing functions like
`array_key_exists`. Also agree that using `exists` instead of `has` is
better. So I updated the function names to `array_path_get` and
`array_path_exists`. I have preferred to keep `get` in the function name
because I think that `array_path` is less clear about what the function
does. RFC and implementation have been updated.


>
> > - Regarding the issue of returning the default if an intermediate
> > segment
> > is not an array, the philosophy of the function is: if the path exists,
> > return the value, otherwise return the default. This cover uses cases
> > like
> > this: in yaml configuration many times you set a config option to ~
> > (null)
> > and this many times indicates "use the default config". So you may have
> > something like:
> >
> > database:
> >     config: ~
> >
> > Indicating that you want to use the default database config. If you
> > convert
> > this yaml file to an array an use the array_get_path function to get a
> > value, for example array_get_path($config, ['database', 'config',
> > 'port'],
> > 7766), you want to get 7766, not an exception or error. Tim points out
> > that
> > intermediate segments might be objects which implement ArrayAccess, but
> > allowing this would complicate the code of the function a lot without
> > much
> > practical gain.
>
> Perhaps the right solution is using =E2=80=9Cisset=E2=80=9D-like semantic=
s instead:
> `null` is treated as an absent entry (it can be debated if an explicit
> `null` at the end of the path should be treated as `null` rather than
> the default), array allows the traversal to continue and everything else
> results in a clear error. This would then allow to extend support to
> anything ArrayAccess in the future without a compatibility break.
> Generally =E2=80=9Cthrowing an error=E2=80=9D is always a safe option.
>
> But saying that `array_get_path(['foo' =3D> '???'], ['foo', 'bar'],
> 'default');` should result in `'default'` doesn't make sense to me and -
> staying with the config example - might mask configuration errors:
>
> As an example, a user might accidentally configure a "DSN":
>
>      database:
>          connection: "mysql://root@db.example.com"
>
> when in reality the library expects separate components:
>
>      database:
>          connection:
>              driver: mysql
>              host: db.example.com
>              user: root
>
> Now extracting the host with `array_get_path($config, ['database',
> 'connection', 'host'], 'localhost')` would erroneously fall back to
> default values instead of reporting a clear error.
>
> I am still unconvinced about this. Your proposal seems to give the `null`
a special value and I think that in general the full semantics are less
clear. And I don't really like the function throwing errors for paths, I
think that this function is great for defensive access to values, where you
can be sure that you don't need to be checking the path all the time. The
existing implementations in Laravel and Lodash do not throw any error if an
intermediate value is not an array (or object for Lodash) and instead
return the default, so I think it is best to keep this behaviour

Cheers

Carlos

--000000000000f820ce064fb5df58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, 15 Apr 2026 at 20:18, Tim D=C3=BC=
sterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&gt; wr=
ote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2026-04-14 19:06, schrieb Barel:<br>
&gt; - I see the point that Tim made about the function names, I have <br>
&gt; updated<br>
&gt; them to array_get_path() and array_has_path()<br>
<br>
Similarly to Rob&#39;s tongue in cheek comment, I think I would also prefer=
 <br>
having a common prefix for the functions, since this improves <br>
discoverability. While there are some inconsistencies in the array API <br>
due to its age, I think there is a reasonably similar precedent with the <b=
r>
`array_key_*()` functions. In fact looking at those, I wonder if the <br>
following pair of names would make sense for your proposed feature:<br>
<br>
- array_path()<br>
- array_path_exists()<br>
<br>
=C2=A0From what I see, the functions in the array API don&#39;t mention =E2=
=80=9Cget=E2=80=9D as <br>
the default operation, e.g. it&#39;s `array_first()`, not <br>
`array_get_first()`. And for =E2=80=9Cexistence checks=E2=80=9D there&#39;s=
 the obvious <br>
precedent with `array_key_exists()` which is also used in the example <br>
implementation in your RFC.<br></blockquote><div><br></div><div>Tim, thanks=
 again for your comments. I did not like using `array_path._...` because th=
e function name reads less naturally, but I agree that it improves discover=
ability and is more in line with existing functions like `array_key_exists`=
. Also agree that using `exists` instead of `has` is better. So I updated t=
he function names to `array_path_get` and `array_path_exists`. I have prefe=
rred to keep `get` in the function name because I think that `array_path` i=
s less clear about what the function does. RFC and implementation have been=
 updated.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">
<br>
&gt; - Regarding the issue of returning the default if an intermediate <br>
&gt; segment<br>
&gt; is not an array, the philosophy of the function is: if the path exists=
,<br>
&gt; return the value, otherwise return the default. This cover uses cases =
<br>
&gt; like<br>
&gt; this: in yaml configuration many times you set a config option to ~ <b=
r>
&gt; (null)<br>
&gt; and this many times indicates &quot;use the default config&quot;. So y=
ou may have<br>
&gt; something like:<br>
&gt; <br>
&gt; database:<br>
&gt;=C2=A0 =C2=A0 =C2=A0config: ~<br>
&gt; <br>
&gt; Indicating that you want to use the default database config. If you <b=
r>
&gt; convert<br>
&gt; this yaml file to an array an use the array_get_path function to get a=
<br>
&gt; value, for example array_get_path($config, [&#39;database&#39;, &#39;c=
onfig&#39;, <br>
&gt; &#39;port&#39;],<br>
&gt; 7766), you want to get 7766, not an exception or error. Tim points out=
 <br>
&gt; that<br>
&gt; intermediate segments might be objects which implement ArrayAccess, bu=
t<br>
&gt; allowing this would complicate the code of the function a lot without =
<br>
&gt; much<br>
&gt; practical gain.<br>
<br>
Perhaps the right solution is using =E2=80=9Cisset=E2=80=9D-like semantics =
instead: <br>
`null` is treated as an absent entry (it can be debated if an explicit <br>
`null` at the end of the path should be treated as `null` rather than <br>
the default), array allows the traversal to continue and everything else <b=
r>
results in a clear error. This would then allow to extend support to <br>
anything ArrayAccess in the future without a compatibility break. <br>
Generally =E2=80=9Cthrowing an error=E2=80=9D is always a safe option.<br>
<br>
But saying that `array_get_path([&#39;foo&#39; =3D&gt; &#39;???&#39;], [=
9;foo&#39;, &#39;bar&#39;], <br>
&#39;default&#39;);` should result in `&#39;default&#39;` doesn&#39;t make =
sense to me and - <br>
staying with the config example - might mask configuration errors:<br>
<br>
As an example, a user might accidentally configure a &quot;DSN&quot;:<br>
<br>
=C2=A0 =C2=A0 =C2=A0database:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection: &quot;mysql://<a href=3D"mail=
to:root@db.example.com" target=3D"_blank">root@db.example.com</a>&quot;<br>
<br>
when in reality the library expects separate components:<br>
<br>
=C2=A0 =C2=A0 =C2=A0database:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0driver: mysql<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0host: <a href=3D"http://db.=
example.com" rel=3D"noreferrer" target=3D"_blank">db.example.com</a><br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0user: root<br>
<br>
Now extracting the host with `array_get_path($config, [&#39;database&#39;, =
<br>
&#39;connection&#39;, &#39;host&#39;], &#39;localhost&#39;)` would erroneou=
sly fall back to <br>
default values instead of reporting a clear error.<br><br></blockquote><div=
>I am still unconvinced about this. Your proposal seems to give the `null` =
a special value and I think that in general the full semantics are less cle=
ar. And I don&#39;t really like the function throwing errors for paths, I t=
hink that this function is great for defensive access to values, where you =
can be sure that you don&#39;t need to be checking the path all the time. T=
he existing implementations in Laravel=C2=A0and Lodash do not throw any err=
or if an intermediate value is not an array (or object for Lodash) and inst=
ead return the default, so I think it is best to keep this behaviour</div><=
div><br></div><div>Cheers</div><div><br></div><div>Carlos=C2=A0</div></div>=
</div>

--000000000000f820ce064fb5df58--