Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130694
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> <CABVsiph+=CeAkAL6XwzD57qDPt=24r8sh4HV32BOPmRFXfTqSw@mail.gmail.com>
 <4f684a4fbad3a7ddb797e24e3c1a882a@bastelstu.be> <8dca7d45-fce4-4d6a-ac56-956046ef20a6@app.fastmail.com>
 <df6ddecef3b8f61583977721dcf9976f@bastelstu.be>
In-Reply-To: <df6ddecef3b8f61583977721dcf9976f@bastelstu.be>
Date: Sat, 25 Apr 2026 21:37:02 +0200
Message-ID: <CABVsipgWoX1bNa69wUi0AmGK4-62WkNsaWj965QT4ocyz9_wCg@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="00000000000028a12306504e0215"
From: barel.barelon@gmail.com (Barel)

--00000000000028a12306504e0215
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Tim,

Many thanks for your comments regarding the RFC, I have updated it.
Regarding the issue of throwing errors if a path cannot be traversed due to
an intermediate step not being an array, I tend to agree with Larry so I am
leaving this as it is for the time being

Cheers

Carlos

On Mon, 20 Apr 2026 at 19:07, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:

> Hi
>
> Am 2026-04-20 17:18, schrieb Larry Garfield:
> > Just to make sure we're talking about the same thing here.  Tim, you're
> > suggesting that this:
> >
> > $a =3D ['foo' =3D> 'bar'];
> > $val =3D array_path_get($a, ['foo', 'bar', 'baz']);
> >
> > Should error rather than returning null?
>
> Yes.
>
> > If the array were clearly, consistently, and properly structured, we
> > could reliably just do $a['foo']['bar'] and move on with life.
> > [=E2=80=A6]
> > So in that sort of case, I'm not sure it's useful to distinguish
> > between "There is no baz key on the array at foo.bar" and "foo.bar is a
> > string, not an array, wat?" [=E2=80=A6]
>
> The goal of the RFC is replacing `$a['foo']['bar']` where the *path is
> dynamic*. Quoting right from the introduction of the RFC:
>
> > When the structure of the array is known in advance and the exact
> > element to retrieve is hardcoded, existing PHP syntax works well [=E2=
=80=A6]
>
> And quoting further from the introduction:
>
> > array_path_get() retrieves a value from a deeply nested array and
> > returns a default value if the path does not exist.
>
> I'm arguing that a =E2=80=9C(value at) path does not exist=E2=80=9D is so=
mething
> fundamentally different from =E2=80=9Cvalue encountered on path cannot be
> traversed further=E2=80=9D.
>
> > converting to an object
>
> I agree that the correct solution in the general case is =E2=80=9Cuse a p=
roper
> object mapper=E2=80=9D (such as Valinor) and don't see much personal valu=
e in
> having the proposed functions. But if they exist, I would want them to
> behave as safely as possible and that includes erroring if they cannot
> make sense of the data. Emitting a Warning when encountering an
> improperly typed value across the path would also work for me, but I
> suppose that others won't be in favor of *that* :-)
>
> Best regards
> Tim D=C3=BCsterhus
>

--00000000000028a12306504e0215
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Tim,<div><br></div><div>Many thanks for your comments rega=
rding the RFC, I have updated it. Regarding the issue of throwing errors if=
 a path cannot be traversed due to an intermediate step not being an array,=
 I tend to agree with Larry so I am leaving this as it is for the time bein=
g</div><div><br></div><div>Cheers</div><div><br></div><div>Carlos</div></di=
v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Mon, 20 Apr 2026 at 19:07, Tim D=C3=BCsterhus &lt;<a h=
ref=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2026-04-20 17:18, schrieb Larry Garfield:<br>
&gt; Just to make sure we&#39;re talking about the same thing here.=C2=A0 T=
im, you&#39;re <br>
&gt; suggesting that this:<br>
&gt; <br>
&gt; $a =3D [&#39;foo&#39; =3D&gt; &#39;bar&#39;];<br>
&gt; $val =3D array_path_get($a, [&#39;foo&#39;, &#39;bar&#39;, &#39;baz=
9;]);<br>
&gt; <br>
&gt; Should error rather than returning null?<br>
<br>
Yes.<br>
<br>
&gt; If the array were clearly, consistently, and properly structured, we <=
br>
&gt; could reliably just do $a[&#39;foo&#39;][&#39;bar&#39;] and move on wi=
th life.<br>
&gt; [=E2=80=A6]<br>
&gt; So in that sort of case, I&#39;m not sure it&#39;s useful to distingui=
sh <br>
&gt; between &quot;There is no baz key on the array at foo.bar&quot; and &q=
uot;foo.bar is a <br>
&gt; string, not an array, wat?&quot; [=E2=80=A6]<br>
<br>
The goal of the RFC is replacing `$a[&#39;foo&#39;][&#39;bar&#39;]` where t=
he *path is <br>
dynamic*. Quoting right from the introduction of the RFC:<br>
<br>
&gt; When the structure of the array is known in advance and the exact <br>
&gt; element to retrieve is hardcoded, existing PHP syntax works well [=E2=
=80=A6]<br>
<br>
And quoting further from the introduction:<br>
<br>
&gt; array_path_get() retrieves a value from a deeply nested array and <br>
&gt; returns a default value if the path does not exist.<br>
<br>
I&#39;m arguing that a =E2=80=9C(value at) path does not exist=E2=80=9D is =
something <br>
fundamentally different from =E2=80=9Cvalue encountered on path cannot be <=
br>
traversed further=E2=80=9D.<br>
<br>
&gt; converting to an object<br>
<br>
I agree that the correct solution in the general case is =E2=80=9Cuse a pro=
per <br>
object mapper=E2=80=9D (such as Valinor) and don&#39;t see much personal va=
lue in <br>
having the proposed functions. But if they exist, I would want them to <br>
behave as safely as possible and that includes erroring if they cannot <br>
make sense of the data. Emitting a Warning when encountering an <br>
improperly typed value across the path would also work for me, but I <br>
suppose that others won&#39;t be in favor of *that* :-)<br>
<br>
Best regards<br>
Tim D=C3=BCsterhus<br>
</blockquote></div>

--00000000000028a12306504e0215--