On Mon, 6 Apr 2026 at 18:12, Larry Garfield <[email protected]> wrote:
> On Mon, Apr 6, 2026, at 10:01 AM, Barel wrote:
> > Following some comments from some users I have decided to also allow
> > the $key parameter to be a list of strings/ints so that this
> > functionality can also be used without using dot notation. I believe
> > this also removes the need to add any kind of dot escaping. If your
> > segments can contain dots, just use the form of the function that
> > accepts an array.
> >
> > It was suggested that accepting an iterable would be a good addition
> > but none of the array_ functions accept an iterable so I don't think it
> > would be good to make an exception here
> >
> > The proposed implementation in GitHub has also been updated with this
> change
> >
> > Cheers
> >
> > Carlos
>
> Please remember to bottom post. :-)
>
> It looks like the RFC hasn't been fully updated for array-based "keys"
> yet. The function signatures in most of the examples still say
> string|int|null.
>
> Despite my long-standing and public crusade against arrays being used
> where an object belongs, I'm overall in favor of this direction. However,
> I would go all-in on the array syntax, not the dotted syntax. There's a
> few reasons for that.
>
> 1. The various notes around escaping. Having a string instruction format
> that doesn't handle escaping and encoding and other edge cases is asking
> for trouble, and it's trouble that will be harder to fix in the future.
> String instructions are always more complicated and nuanced than you
> expect, so a simple "split on the dot and now it's an array!" approach is
> just too rudimentary to be trustworthy, for all the reasons mentioned in
> previous posts.
>
> 2. If you're not building the path dynamically, then there is little
> advantage of it over what we have now.
>
> array_get($array, 'foo.bar.1.baz', null);
>
> $array['foo']['bar'][1]['baz'] ?? null
>
> The second may be slightly slower to type because of the punctuation, but
> it's perfectly viable today.
>
> Where it becomes interesting is when the path is variable... and if the
> path is variable, I'll probably want to be building it dynamically rather
> than just selecting one of a few hard-coded options. And if I'm building
> it dynamically, then string concatenation is an awful way to do that, for
> all the escaping reasons mentioned previously. We're back to concatenating
> SQL strings together, with all the risk that entails.
>
> So I would be in favor of going all the way to
>
> function array_get(array $array, array $path, mixed $default = null) {}
>
> Or, for that matter, that is nearly the same as:
>
> function array_get(array $array, array $path) {}
>
> array_get($arr, $path) ?? null;
>
> Which would allow using a variadic for the $path if desired, instead of an
> array. I'm not certain that's optimal, but I think it's worth discussing.
> array_has() would then follow suit.
>
> Then, separately, I would be in favor of a full-on JSON Pointer
> implementation that can work on both arrays and JSON blobs, potentially (as
> the two are effectively isomorphic). Skip a custom dot notation. Go
> straight to the fully robust standard. Do not pass go, do not collect 200
> security reports.
>
> --Larry Garfield
>
Larry,
Thanks for pointing out that I had not updated the example code to include
array in the type, this has now been updated
You raise some interesting points in your message. I would like to hear
what other people think about them
Cheers
Carlos
