Provide a means to change the context node

[schibsted]

Provide a means to change the context node

[larsga]

So, you want the output to be [1, 2, 3]? Just checking that I've got the idea right.

[ecerulm]

yes, and just for completeness

{
   "z": .a.b | {
       "y": .,
       "x":.
   }
}

should give { "z": {"y": 1, "x": 1}}

[larsga]

Yes, I agree. After the pipe comes any expression you want, with . now meaning the value you computed before the |.

I've been seriously considering this addition to the language for a long time, so I think we'll just do this one.

[larsga]

After some pondering I think I know how this should work https://github.com/schibsted/jslt/blob/master/ideas/matcher.md

[ecerulm]

Doesn't the part

Object key: add the key to the matcher query. So if the matcher is inside "foo" : then prepend .foo to the query.

make a non-backwards compatible change to the language?

Imagine that I had a pre-existing JSLT file:

{ "foo": .bar }

and a input value

{ 
  "foo": {
     "bar": 1
   },
   "bar": 2
}

With JSLT syntax as it is today that JSLT + input will produce output {"foo": 2} , and with the proposed change it will produce {"foo": 1}, if I understood it right.

[larsga]

No, that's part of how object matching in JSLT has worked all along, although it may not be obvious. That's why if you write:

{
  "foo" : {
    "bar" : 2,
   * : .
  }
}

the object matcher will match the object in the foo key in the context object.

The object matcher is the * : . part, not .bar. I guess that's where the confusion comes from.

[larsga]

I've found a case where I really need this and dynamic keys (issue #56). I want to take an object, remove the "item" key, and replace it with a dynamically computed key. Right now I have to do this:

    "parameters" : [{for ($json.customParameters)
      .key : .value if (.key != "item")
    } +
    // workaround for absence of dynamic keys (issue #56)
    {for ([[
      (if (is-string($item))
        "stringItem"
      else
        ""), $item]])
      .[0] : .[1]
    }]

It's ugly as sin. But with the pipe and dynamic keys it becomes:

  "parameters" : [$json.customParameters | {
    (if (is-string($item))
       "stringItem"
     else
       "") : $item,
    * - "item" : .
  }]

Clearly this is what we need.

[ecerulm]

We haven't discussed the operator precedence and associativity or how the interaction with the for-expression, object-for-expresson and if-expression should look like.

I've prepared a PR #109 in which I implemented a preliminary solution.

In that PR pipe operator is implemented has having highest precedence so
1 + 2 | (. * 5) equals 11 as its interpreted as 1 + (2 | (. * 5)) which reduces to 1 + ((2 * 5)).

To be honest I think it feels like it should have lower precedence than the arithmetic operators so that 1 + 2 | (. * 5) equals (1 + 2) | (. * 5) -> 3 | (. * 5) -> 15. But not lower than and/or operators so that true or false | { "a" : .} evaluates to true and not to {"a": true}. @larsga what do you think?

Then associativity I assume it should be left-associative so that 1 | (. *2) | ( . + 3) | (. * 5) is interpreted as 1 | (. * 2) evaluated first and the result feeded to | (. +3) and so on.

I can prepare other test with {if-expressions, for-expressions, object-for-expressions} on both sides of the operator if the PR is inline with what you had in mind @larsga

[ecerulm]

Just for future reference: at the end we didn't implement the operator precedence as described in previous comment. We made pipe operator the lowest precedence, so that means lower than and / or operators.