Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130573
Precedence: list
MIME-Version: 1.0
References: <CABVsipicHroAcWJSEpjwM4+y6p-6axV-6tO__MejThESFVCP3A@mail.gmail.com>
 <1775371239896.1388335648.2022649470@yahoo.de>
In-Reply-To: <1775371239896.1388335648.2022649470@yahoo.de>
Date: Sun, 5 Apr 2026 11:43:03 +0200
Message-ID: <CABVsipg7tPv8roLP4CpJRBeK_beds-R-_DE7DXKnznZsd5UbiQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
To: Hans Krentel <hanskrentel@yahoo.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000020deae064eb36115"
From: barel.barelon@gmail.com (Barel)

--00000000000020deae064eb36115
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 5 Apr 2026 at 10:13, Hans Krentel <hanskrentel@yahoo.de> wrote:

>
> On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:
>
> > Hi,
> >
> > I would like to open the discussion on my proposal to add two small,
> > focused array functions for retrieving and checking nested array elemen=
ts
> > using dot notation.
> >
> > This is the link to the RFC:
> > https://wiki.php.net/rfc/array_get_and_array_has
> >
> > This is the link to the proposed implementation:
> > https://github.com/php/php-src/pull/21637
> >
> > Thanks!!
>
> Thank you very much! That=E2=80=99s very interesting, so I have to ask ri=
ght away:
> Is there a specific reason to limit this to strings, integers, and null f=
or
> arrays, rather than also allowing arrays or iterables?
>
> This reminds me of JSON Pointers (RFC 6901), which can usually be easily
> mapped as an iterable with string keys, which can then be accessed via th=
e
> holder variable, similar to the foreach example you already describe in
> your RFC.
>
> If these two functions supported passing an array/iterable with the
> traversal keys as a second parameter, this would be advantageous, since t=
he
> JSON pointer would then not need to be recoded into dot notation, but onl=
y
> (if not already done) sliced and passed as an array as the second paramet=
er.
>
> That's why I'm asking.
>
> Interestingly, JSON Pointer solves the =E2=80=9Cnull problem=E2=80=9D by =
prefixing the
> zero or more reference tokens (keys) with a slash =E2=80=98/=E2=80=99, an=
d it supports all
> seven types of JSON values without limiting itself to just JSON arrays or
> objects. This is just food for thought: array_... are clearly array
> functions, so this =E2=80=9Crestriction=E2=80=9D is likely intentional. I=
n PHP, however, I
> can also imagine iterables that resemble what you=E2=80=99ve already desc=
ribed in
> your RFC, and from there it=E2=80=99s not far to the holder object we see=
 in JSON
> and JSON Pointer. So please don=E2=80=99t confuse my =E2=80=9Crequest=E2=
=80=9D regarding
> arrays/iterables with the first parameter; it=E2=80=99s simply about pass=
ing the
> key as a keys, which is a small improvement over dot notation.
>
> With arrays in PHP, users will likely prefer the non-standard, more custo=
m
> dot notation, and that=E2=80=99s perfectly fine. I saw many people asking=
 for this
> in the early days of Stack Overflow, and if Symfony/Laravel have it as
> well, that=E2=80=99s just another strong indication of such a preference.
>
> Thanks again for your RFC
>
>
> --hakre
>
> P.S. Work on the RFC documentation for JSON Path finally began in 2020,
> and it was published in February 2024. The standard has its roots in PHP
> and JavaScript, and perhaps it=E2=80=99s time for PHP to expand its stand=
ard
> library with such features at the same pace we did with JSON. Your RFC
> seems well-suited for this purpose. Thanks again.
>

Thanks for your comments. Someone else already suggested allowing arrays
for the $key parameter and I am considering it, I think it will probably be
a good addition

Cheers

Carlos

--00000000000020deae064eb36115
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, 5 Apr 2026 at 10:13, Hans Krentel=
 &lt;<a href=3D"mailto:hanskrentel@yahoo.de">hanskrentel@yahoo.de</a>&gt; w=
rote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><br>
On Saturday 04 April 2026 16:06:21 (+02:00), Barel wrote:<br>
<br>
&gt; Hi,<br>
&gt; <br>
&gt; I would like to open the discussion on my proposal to add two small,<b=
r>
&gt; focused array functions for retrieving and checking nested array eleme=
nts<br>
&gt; using dot notation.<br>
&gt; <br>
&gt; This is the link to the RFC:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/array_get_and_array_has" rel=3D"no=
referrer" target=3D"_blank">https://wiki.php.net/rfc/array_get_and_array_ha=
s</a><br>
&gt; <br>
&gt; This is the link to the proposed implementation:<br>
&gt; <a href=3D"https://github.com/php/php-src/pull/21637" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/php/php-src/pull/21637</a><br>
&gt; <br>
&gt; Thanks!!<br>
<br>
Thank you very much! That=E2=80=99s very interesting, so I have to ask righ=
t away: Is there a specific reason to limit this to strings, integers, and =
null for arrays, rather than also allowing arrays or iterables?<br>
<br>
This reminds me of JSON Pointers (RFC 6901), which can usually be easily ma=
pped as an iterable with string keys, which can then be accessed via the ho=
lder variable, similar to the foreach example you already describe in your =
RFC.<br>
<br>
If these two functions supported passing an array/iterable with the travers=
al keys as a second parameter, this would be advantageous, since the JSON p=
ointer would then not need to be recoded into dot notation, but only (if no=
t already done) sliced and passed as an array as the second parameter.<br>
<br>
That&#39;s why I&#39;m asking.<br>
<br>
Interestingly, JSON Pointer solves the =E2=80=9Cnull problem=E2=80=9D by pr=
efixing the zero or more reference tokens (keys) with a slash =E2=80=98/=E2=
=80=99, and it supports all seven types of JSON values without limiting its=
elf to just JSON arrays or objects. This is just food for thought: array_..=
. are clearly array functions, so this =E2=80=9Crestriction=E2=80=9D is lik=
ely intentional. In PHP, however, I can also imagine iterables that resembl=
e what you=E2=80=99ve already described in your RFC, and from there it=E2=
=80=99s not far to the holder object we see in JSON and JSON Pointer. So pl=
ease don=E2=80=99t confuse my =E2=80=9Crequest=E2=80=9D regarding arrays/it=
erables with the first parameter; it=E2=80=99s simply about passing the key=
 as a keys, which is a small improvement over dot notation.<br>
<br>
With arrays in PHP, users will likely prefer the non-standard, more custom =
dot notation, and that=E2=80=99s perfectly fine. I saw many people asking f=
or this in the early days of Stack Overflow, and if Symfony/Laravel have it=
 as well, that=E2=80=99s just another strong indication of such a preferenc=
e.<br>
<br>
Thanks again for your RFC<br>
<br>
<br>
--hakre<br>
<br>
P.S. Work on the RFC documentation for JSON Path finally began in 2020, and=
 it was published in February 2024. The standard has its roots in PHP and J=
avaScript, and perhaps it=E2=80=99s time for PHP to expand its standard lib=
rary with such features at the same pace we did with JSON. Your RFC seems w=
ell-suited for this purpose. Thanks again.<br></blockquote><div><br></div><=
div>Thanks for your comments. Someone else already suggested allowing array=
s for the $key parameter and I am considering it, I think it will probably =
be a good addition</div><div><br></div><div>Cheers<br><br>Carlos=C2=A0</div=
></div></div>

--00000000000020deae064eb36115--