Re: [Jsonpath] Suggestion for distinct semantics of the descendant segment

[Carsten Bormann <[e-mail]>]

Mi Mateusz,

thank you again for your continued input.

> On 2023-06-15, at 15:47, Mateusz Gienieczko <mat=[e-mail]> wrote:
> 
> Signed PGP part
> 
>> We don't have any precedent for function selectors at this time, and I'm not sure what the syntax would be in the context of the path.
> 
> This might not generalize well enough to be put into any place in the path. But limiting this to be a top-level function would probably enough. I cannot come up with a non-contrived example for a query that a user would want to give distinct nodes in one place and non-distinct in another.
> 
> So, the proposal would be to have the ability to write a query of form `func(query)`. Of the top of my head, a modifier like count(q)​, returning number of nodes matched, would also be useful.

We need to be careful about completely leaving the current structure:  Right now results of queries are always nodelists of nodes that are in the initial query argument.  Count(q) isn’t.

We have been calling functionality of this kind “transformation”, as opposed to the “selection” functionality we have now.  “Projection” of course can be a form of “transformation” and has also been asked for (give me those objects, but with all members deleted except these two).

Reducing nodelists to distinct entries definitely is selection and would cause none of this pain.

> However, the main gripe here is that (let's call them) distinct descendant semantics are not even allowed in any way in the current spec. 

I’m not sure I’m reading you right, but we cannot “allow” that behavior without creating interoperability problems.  We would have to specify it.

> […]
>> I think the idea for a "distinct" operator `!` that can be appended to any selector is pretty neat, though.  This would also be applicable to cases like `$['a','a']!`.
> 
> That case is one more that might cause non-linear result sizes, but we deemed it not an issue simply because it's silly :)

We generally try to come up with short examples demonstrating a specific effect, even if they are silly.  So this is not a “motivating” example, just a “demonstrating” one.

So you did generate a “motivating” example:

> $..['a', *[@?.x]]​
[…]
>  I can imagine someone wishing for distinct semantics here, however.

I can, too.  But not distinct semantics for this example, but a way to specify distinct semantics.

See my previous message for why I don’t think we should do this now.
To be clear, this my opinion is not cast in concrete.

Grüße, Carsten