.length needs to be addressed

[gregsdennis]

Ref: #153 (comment)

The original post shows examples of a .length syntax that allows the user to get the number of elements in an array. This was primarily used in the [(<expr>)] syntax such as [(@.length-1)] as a way to denote the last element in an array. For now, we have elected to exclude this syntax.

The .length syntax can also be used in the [?(<expr>)] syntax such as [?(@.length<10)] to find array elements which are objects or arrays which themselves have fewer than 10 keys/items.

However, there is an ambiguity between length as a property of an array and length as an object key. We need to address this ambiguity.

As of opening this issue, the syntax is disallowed, implying it can only have the "object key" semantics. But since the vast majority of implementation support this (object / array), it can be inferred that path authors use this feature. Therefore, we need to support this feature in some way.

Due to the ambiguity stated above, I think we need an alternate syntax. To start, I would like to propose the function syntax length(@) which would return the number of items in an object/array or 0 for non-structured values.

It is recognized that we don't yet have a function syntax defined, so maybe that needs to be addressed first. I'm also open to other proposals that wouldn't require that we define a new class of syntax.

[nichtich]

How about a plain keyword?

$..[?length > 0] get all non-empty arrays (and objects?)

[gregsdennis]

Thanks for the idea, but just the keyword doesn't allow for applying the function to nested values. For example, you couldn't do this: $[?(@.foo[6].length > 10)] which is something many implementations support today.

A function syntax could handle it though: $[?(length(@.foo[6]) > 10)].

[nichtich]

The example could be written as $[? @.foo[6][?length>10] ] or $ ?(@.foo[6] ?(length>10) ) but a function syntax (with virtual property .length for backwards compatibility) seems easier to use. By the way SQL JSON/Path does not have a length function but the method .size() working like the virtual property .length. This could be an alternative to functions (with limtation pointed out by you):

• $.length - size or property length, depending on context
• $.length() or $.size() - always size

[gregsdennis]

$[? @.foo[6][?length>10] ] or $ ?(@.foo[6] ?(length>10) )

That's a lot of additional syntax that would have to be supported.

$.length - size or property length, depending on context

This is the problem that we're trying to address with this issue. How do you specify that you want length of there is a length property?

[nichtich]

$.length - size or property length, depending on context
This is the problem that we're trying to address with this issue. How do you specify that you want length of there is a length property?

As far as I understand .length returns the length property on JSON objects and the array size on JSON arrays.

• https://cburgmer.github.io/json-path-comparison/results/dot_notation_with_key_named_length.html
• https://cburgmer.github.io/json-path-comparison/results/dot_notation_with_key_named_length_on_array.html

Or drop support of .length on arrays. Either way some current implementations will not conform to the upcoming specification.

That's a lot of additional syntax that would have to be supported.

I think the question of this issue is

1. whether ​to support existing implementations that allow .length on arrays or support existing implementations that don't allow .length on arrays,
2. whether to add some other feature to get array length

[gregsdennis]

As far as I understand .length returns the length property on JSON objects and the array size on JSON arrays. - @nichtich

It does this historically because @goessner's implementation did this. His implementation use the inherent Javascript and PHP meanings behind the syntax. But this spec effort is striving for language agnosticity, which means we can't rely on that syntax. We need something more well-defined that works interoperably.

The question at hand is as I stated it in the opening comment:

Due to the ambiguity stated above, I think we need an alternate syntax.

This is akin to your # 2. I think we have already decided fairly unilaterally that we will not be supporting .length due to the ambiguity it presents, which I had also stated in the opening comment:

As of opening this issue, the syntax is disallowed.

[danielaparker]

Either way some current implementations will not conform to the upcoming specification.

That's not an issue :-) All current implementations will not conform to the upcoming IETF specification. And the important ones wouldn't be able to change, as they're part of widely used API's that have been around for years, for example, in Kubernetes, in Oracle Java enterprise platforms, and so on. It's also hard to see how the widely used implementations that use Javascript, Python or PHP for expressions could change. No, the IETF specification is best thought of as something new that new implementations of JSONPath could target.

[nichtich]

@gregsdennis wrote:

I think we have already decided fairly unilaterally that we will not be supporting .length due to the ambiguity it presents

Then this issue can be closed. Whether and how to support other methods to access and/or filter (by) number of elements would be an additional feature request.

[cabo]

I'm not sure what was unilateral about this decision, and we haven't confirmed it on the mailing list, but I agree that .length would be an odd addition to the current draft.

What we haven't decided is whether there should be ways to find out information about a JSON value being looked at, such as the length of the string, the size of an array, or the number of pairs in a JSON object.

[gregsdennis]

This issue can't be closed yet, for the reason @cabo suggested: we should still support the functionality, but the syntax will be different.

[glyn]

This was addressed as part of the function extension point work.