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
