Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130646
Precedence: list
MIME-Version: 1.0
Date: Wed, 15 Apr 2026 20:18:22 +0200
To: Barel <barel.barelon@gmail.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] array_get and array_has functions
In-Reply-To: <CABVsipjQiay5NK36Rwtwk6tDi0mRwa+Wv4oSz17qR_vwresYfw@mail.gmail.com>
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>
Message-ID: <19d58a46b50222b75da4e40e417efd05@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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 “get” as 
the default operation, e.g. it's `array_first()`, not 
`array_get_first()`. And for “existence checks” there's the obvious 
precedent with `array_key_exists()` which is also used in the example 
implementation in your RFC.

> - 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 “isset”-like semantics 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 “throwing an error” is always a safe option.

But saying that `array_get_path(['foo' => '???'], ['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.

Best regards
Tim Düsterhus