On Mon, 13 Apr 2026 at 17:23, Larry Garfield <[email protected]> wrote:
> On Sat, Apr 11, 2026, at 5:30 AM, Barel wrote:
>
> > After the discussion here and after speaking to other developers, I
> > have decided to drop the dot notation entirely from this RFC and only
> > leave the option to use an array path. Using dot (or similar) notations
> > can be easily achieved using a simple explode or more complex code if
> > we need to do more complex setups like escaping. The main goal of the
> > RFC has always been being able to handle dynamic paths. The
> > implementation has also been updated and is now much simpler
> >
> > Cheers
> >
> > Carlos
>
> "4) Using dot or similar notations "
>
> This should be bullet point 3, not no 4.
>
> I agree with Tim that an invalid path segment should error in some way,
> rather than just using the default. If a non-int/string path segment is
> encountered, it 100% of the time means the developer screwed up in some way
> so they should know to fix it.
>
> One of the most common uses for structure-unclear arrays I run into is
> (bad) APIs that have a value that is either a primitive or an array of
> primitives. Can you include an example showing how these functions would
> help in that situation?
>
> Eg, this JSON:
>
> { "state": "IL" }
> vs
> {"state": ["IL", "CA", "NY"] }
>
> Presumably you also have some real-world cases in mind that you've run
> into. Can you include versions of those in the examples to get a better
> sense of what usage would look like in practice?
>
> To Tim's naming point, perhaps `array_has_path()` / `array_get_path()`?
> (Or maybe `path` first, not sure.)
>
> --Larry Garfield
>
Tim, Larry
Many thanks for your thoughtful comments.
- I updated the bullet point number
- I agree that if an invalid path segment is found it is better to throw a
TypeError, this has been updated
- I see the point that Tim made about the function names, I have updated
them to array_get_path() and array_has_path()
- 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.
BTW, the URL to the RFC has changed and is now
https://wiki.php.net/rfc/array_get_path_and_array_has_path
Cheers
Carlos
