Hi
Am 2026-04-18 08:06, schrieb Barel:
`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.
No strong preference regarding the `_get()` suffix from my side.
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
null being a value indicating absence is by no means “special” in my
suggestion. As previously mentioned, it's the semantics of `isset()`.
It's also what `array_find()` and `array_find_key()` return. It has
special syntax in types with the questionmark in `?Type`. It's what you
get when you read a non-existent value.
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
Defensive access to me also implies throwing errors *where appropriate*,
namely trying to perform an operation that is not meaningful. Trying to
access an array offset on a string is not meaningful and trying to do
*something* is not likely what the user intended to do. Similarly users
passing in `ArrayAccess` objects might reasonably expect them to “just
work”. Returning a default value instead of a clear error will likely
lead to them thinking they found a bug in PHP.
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
I don't think that lodash is quite comparable here, because JavaScript
is quite different to PHP in that *everything* is an object. Thus
`_.get({"foo": "bar"}, "foo.length.toString")` is meaningful (namely it
returns `Number.prototype.toString()`).
As for the Laravel comparison, from what I see, they *do* support any
`ArrayAccess`, so the function is also not comparable.
I've also taken another look at the RFC and have the following
additional comments:
- The “Invalid array path segments” example is outdated, `stdClass` in
the path should throw.
- The types of the path-segments should be pre-validated for consistent
error reporting. Meaning:
array_path_get($array, ['foo', 'bar', new stdClass()])
should consistently throw, independent of whether `$array` is `[]`,
`["foo" => []]`, `["foo" => ["bar" => []]` or something else.
- I also wonder if `$path` should just be `string[]` instead of
`(int|string)[]`. In the context of array keys, `"123"` is equivalent to
`123` anyways.
Best regards
Tim Düsterhus
