Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Maxime Labelle
    @springcomp
    It’s the same as a.b || c.d really.
    image.png
    hell-racer
    @hell-racer
    OMG!
    How did you do that?
    Maxime Labelle
    @springcomp
    I did nothing. It just works™.
    I was .not thinking straight when I argued the JEP
    hell-racer
    @hell-racer
    That's fantastic )
    So, according to Preview Features root-access syntax ($.abc) isn't making it into the spec?
    Maxime Labelle
    @springcomp

    @hell-racer , you know @innovate-invent and I are just two guys on the Internet.
    You can have a voice.
    And the more community members are involved, the better.

    We are having quite some heated debates with regards to $.
    Currently, it is being specified as a JEP, as you may have seen, but due to some debate, I feel it cannot be included in the very next immediate short term milestone.

    But I would love to have those discussions.

    My position is that $ as the root node is quite handy and is worthy of inclusion.
    I think @innovate-invent wants $ to have a more ambitious destiny.
    This is central to the reduce feature.
    Currently, we both think that JMESPath needs a reduce feature.
    image.png
    My position is that, since we have map() we should have reduce().
    To perform some sums, products, aggregates, etc.
    Nolan Woods
    @innovate-invent
    My position is that map() was a mistake
    Maxime Labelle
    @springcomp
    image.png
    @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.
    Nolan Woods
    @innovate-invent
    I would rather see we don't compound that mistake
    hell-racer
    @hell-racer
    My thought is that $ as a root access will be intuitive since JsonPath has it, and a lot of people come from JsonPath to JmesPath when they stumble upon some unsolvable problem.
    Maxime Labelle
    @springcomp
    @hell-racer the preview feature page is incomplete.
    Preview actually include all the string manipulation functions, a new map_by() function that we feel uses the correct order for its arguments.
    And many more.
    Nolan Woods
    @innovate-invent
    @hell-racer, how would you feel about making backwards incompatible changes?
    you seem to spend a lot of time working with JMESPath
    Maxime Labelle
    @springcomp
    @hell-racer feel free to review the discussions around $ in the spec repository.
    hell-racer
    @hell-racer
    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.
    Maxime Labelle
    @springcomp
    @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?
    hell-racer
    @hell-racer
    For some reason, I didn't encounter a single task where I would need reduce, so in my case $ would be better just as the root node. But I understand there are certainly some cases where reduce will be handy.
    Maxime Labelle
    @springcomp
    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.
    hell-racer
    @hell-racer

    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?

    Maxime Labelle
    @springcomp
    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.
    hell-racer
    @hell-racer

    null is "falsie", so it would work with other logical expressions, e.g. (considering it will return null instead of throwing):

    length(abc) > `0` && contains(def, 'ghi') && 'yes' || 'no'

    This would correctly return 'yes' or 'no' even if some nodes are missing.

    Maxime Labelle
    @springcomp
    Yes definitely.
    Nolan Woods
    @innovate-invent
    What about my try() function proposal?
    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.
    hell-racer
    @hell-racer
    That's even longer than length(null || []) :)
    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.
    Nolan Woods
    @innovate-invent
    what about length(null) || 0
    hell-racer
    @hell-racer
    Currently it throws, but I'd definitely use this if it returned 0.
    Nolan Woods
    @innovate-invent
    I just don't like the idea that I can't use null as a legitimate value in an expression
    hell-racer
    @hell-racer
    Yeah
    I think it's ok if functions throw errors in case of other incompatible types (except null).
    e.g. contains(1, 2)
    Nolan Woods
    @innovate-invent
    try(length(abc) > `0` && contains(def, 'ghi') && 'yes' || 'no', 'no')
    in this case, if abc or def are undefined, then it will work
    basically, it allows expressions to ask for forgiveness rather than permission
    hell-racer
    @hell-racer
    So in my case most expressions would start with try :). Having to write 'no' two times in your example isn't optimal too...
    Nolan Woods
    @innovate-invent
    yea, but if try() moved on to the next expression based on truthyness then that would not allow legitimate falsy values