This is central to the reduce feature.
Currently, we both think that JMESPath needs a reduce feature.
My position is that, since we have
map() we should have reduce().
To perform some sums, products, aggregates, etc.
@innovate-invent would rather have that implemented as syntax:
That’s where
$ could play a role, by representing the currently being accumulated value in the reduce operation.
you seem to spend a lot of time working with JMESPath
Yeah... since I've implemented an integration service using a templating engine based on JmesPath, all the integrations are done by using these templates :). We write C# code when we need another custom function or to call some new service for additional source data, everything else is done via templates :).
I feel ok when breaking changes are under some feature toggles, but I imagine it's hard to do when we're talking about spec and not about concrete implementation.
It is also possible to version entire spec... I remember Python had some breaking changes from 2 to 3. But when it's necessary to support more than one spec it's not very convenient.
I feel ok when breaking changes are under some feature toggles, but I imagine it's hard to do when we're talking about spec and not about concrete implementation.
It is also possible to version entire spec... I remember Python had some breaking changes from 2 to 3. But when it's necessary to support more than one spec it's not very convenient.
@hell-racer among the would-be JEPs that we did not include in the next milestone (yet), are there some you feel need to be included right away?
That’s really interesting. Have you seen other uses cases, maybe amongst those that are just rough ideas and that we would then need to elaborate with higher priority?
And thank you for your feedback. This is very valuable.
There is some caveat when using functions... Imagine you're accessing a node, and there is no such node. So it just returns null. But when you use a function, such as length(), if its argument evaluated to null it throws an error. So we have to check the node first every time we use length() or use a fallback in the argument:
abc && length(abc) > `0`or
length(abc || []) > `0`Would it be nice if it just returned null instead of throwing an error?
That's an interesting point. It maybe goes with one concern @innovate-invent has, with projections filtering null values. So on the one hand we have a feature that tries to protect us from nulls ; but on the other hand functions a more stricly typed. I can certainly agree that null should be considered a valid value of all types so, yes, your suggestion makes sense.
try(length(null), null)
I would actually prefer null not be used as a sentinel value. It would be better for either an error to be raised in all cases, or use a special
undefined value.
To me it looks like an error should be raised only if there is a syntax error, e.g. incorrect function name or incorrect expression.
I think it's ok if functions throw errors in case of other incompatible types (except
null).
e.g.
contains(1, 2)
in this case, if abc or def are undefined, then it will work
basically, it allows expressions to ask for forgiveness rather than permission
try([&length(abc) > `0` && contains(def, 'ghi') && 'yes' || 'no', &'no']) would be the actual syntax
better just a random value