Re: [RFC] [Discussion] array_get and array_has functions

On Mon, 6 Apr 2026 at 18:12, Larry Garfield <larry@garfieldtech.com> 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