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://[email protected]"
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
