Advanced usages of expressions

[gregsdennis]

Would we consider allowing advanced expressions usages?

As a comparable (as named in the ABNF)

Path
    $[?@.foo == (@.bar < 10)]

Data:
    [
      { "id": 1, "foo": true, "bar": 5 },
      { "id": 2, "foo": false, "bar": 5 },
      { "id": 3, "foo": true, "bar": 50 },
      { "id": 4, "foo": false, "bar": 50 }
    ]

This would return the objects with ids 1 and 4.

As a function argument:

Path
    $[?sqrt(@.foo + @.bar) < 10)] 

Data:
    [
      { "id": 1, "foo": 5, "bar": 5 },
      { "id": 2, "foo": 50, "bar": 51 }
    ]

(Yeah, we don't support + currently, but the example illustrates the idea.)

This would return the object with id 1.

There are probably other ways expressions could be used, too.

[glyn]

Note that function extensions, with the improvements anticipated in https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/330, may be able to address the above use cases:

$[?@.foo == lessThan(@.bar, 10)]

$[?sqrt(add(@.foo, @.bar)) < 10)]

[gregsdennis]

I think what I've written is probably the more intuitive given the gamut of features in programming languages available today. What you have is definitely more functional (i.e. functional programming style), but I would tend toward using the operators for these examples.

This issue isn't about "how could this be done with what we have?" but rather "is this something we want to support?"

[gregsdennis]

Interestingly, I found a test in the comparison project that treats an expression as a comparable: $[?((@.key<44)==false)].

[glyn]

$[?((@.key<44)==false)]

Here's a link to the test. There is no consensus among implementations, although 14 of them behave the way this issue is proposing. (Embarrassingly, my Go implementation gets just the opposite of that result. That looks like a bug IIRC.)

[cabo]

2023-01-10 Interim: Do not do this enhancement.