Subject: [Jsonpath] Filter Selector: index() the evolution of @name?

From: Joel Bruner <[email-masked]>
Date: Sat, 12 Feb 2022 18:54:34 -0600

I wanted to ask about the Filter Selector 3.5.9 and the new index() "function" (neé @name?)

In the original Goessner code is a bit of an easter egg by the name of @name [1] (hidden as _vname before substitution) This allows for the property name of an object or an array index to figure into the the filter. The syntax was admittedly weird but useful for cases where an exact key name is either unknown or where multiple keys can be matched with regex. [2]

In Table 6 of 3.5.9 there's a new function-like thing called index() which seems to be the successor to @name? This is good news that this functionality is stepping out of the shadows and getting better syntax but there doesn't seem there's any more info in the draft on index()? I'm very curious and encouraged that @name lives on in a new form.

Somewhat related, since the .length syntax "needs to be addressed" [3] will it go the way of the index() style? (I suppose the new style has yet to be accepted?) And will length() work on objects by counting members? If I missed this in a GH issue convo pardon :]

Thanks,
Joel

[1]: jsonpath-0.8.0.js.txt, line 76 - "eval: function(x, _v, _vname)"... https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/jsonpath/jsonpath-0.8.0.js.txt

[2] jpt (https://github.com/brunerd/jpt) example of @name usage:
	% jpt -i0 '$[?(@name === 0 || @name > 3)]' <<< '[0,1,2,3,4,5,6,7]'
	[0,4,5,6,7]

	% jpt -i0 '$[?(@name =~ /key.*/)]' <<< {"key_a":1,"key_b":2,"keep":3}  
	[1,2]

[3] ".length needs to be addressed" - 
https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/154

---

From: Stefan Gössner <[email-masked]>
Date: Wed, 16 Feb 2022 16:55:19 +0100

I didn't implement any easter eggs in my initial implementation ... at 
least not consciously :)
You finally managed, that I inspected my former code in more detail 
again after that time.

IIRC, I implemented that feature just for testing and obviously finally 
failed to document it. It was discussed here recently in depth.

https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/109

In short ... for

{ "a":1, "b":2, "c":3 }

the query '$[?@]' will return values only, but if we want to have access 
to the corresponding names (name/value pairs) for some reason, we are lost.

This is, what '@name' ($[?@name != 'c']) in my original implementation 
and recently 'index' (index/value pairs) was meant for.

Two proposals were discussed in issue 109:

1) 'index(@)'  functional approach
2) '@index'    accessor approach

Shortcomings of 1) are ...

* what kind of arguments were accepted here apart from '@' ?
* how correlates 'index' to current member/element '@' then ?
* why not allow 'my_favourite_function_name(@,x,y,z)' then ?

Proposal 2) seems to be superior here, as it rigidly connects 'index' to 
current member/element '@'.

btw: 'length' could be resolved the same way.
--
sg

Am 13.02.2022 um 01:54 schrieb Joel Bruner:
> [1]: jsonpath-0.8.0.js.txt, line 76 - "eval: function(x, _v, _vname)"...https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/jsonpath/jsonpath-0.8.0.js.txt
>