ietf-wg-jsonpath / draft-ietf-jsonpath-base

Development of a JSONPath internet draft
https://ietf-wg-jsonpath.github.io/draft-ietf-jsonpath-base/
Other
59 stars 20 forks source link

Crush spaces? #273

Closed timbray closed 1 year ago

timbray commented 1 year ago

There are lots of places in the grammar where optional space is allowed, e.g.

slice-selector =  [start S] ":" S [end S] [":" [S step ]]

Would it be a good idea to crush them all out? We wouldn't lose any backward compatibility, we'd remove a lot of optional operations for implementers, and we'd get more compatible expressions. We might lose readability, but not much.

glyn commented 1 year ago

Crushing out all spaces would simplify testing and I agree it wouldn't impact the readability of simple paths much.

On the other hand, implementers using parser generators won't have to write code to handle whitespace and those using hand-crafter parsers or parser combinators can easily code up a whitespace handling routine which can be used where necessary.

When it comes to complex paths, I think the readability impact of crushing out all whitespace may be significant. E.g. compare

$.a[?@ < 2 || @.b == "k", ?@.c > $.d]

to

$.a[?@<2||@.b=="k",?@.c>$.d]

That said, I think it would be unusual to use whitespace in slices, e.g. [1: 10: 2] or [1 : 10 : 2] don't seem more readable than [1:10:2], so there may be a case for crushing whitespace out of specific productions such as slice-selector.

timbray commented 1 year ago

Not passionate about this one, but I do like the idea of removing them from slices.

glyn commented 1 year ago

In addition to removing whitespace from slices, we might also consider removing all whitespace, except that following the comma selector separator, from child (and hence descendant) segments, i.e. replacing:

child-longhand            = "[" S selector 1*(S "," S selector) S "]"

with

child-longhand            = "[" selector 1*("," S selector) "]"
glyn commented 1 year ago

I did think of a readability concern for slices. Suppose there is some kind of list of paths and it was more readable to line up the slice components, e.g.:

$[  0 :   5 : 2]
$[ 10 :  15 : 2]
$[ 20 :  25 : 2]
$[ 30 :  35 : 2]
...
$[100 : 105 : 2]

Compare this to the crushed alternative:

$[0:5:2]
$[10:15:2]
$[20:25:2]
$[30:35:2]
...
$[100:105:2]

I'm not sure that's a deal-breaker for "crushed" slices, but it's worth thinking about. (It is also relevant to child segment whitespacing because of the whitespace after [.)

cabo commented 1 year ago

Blank space also includes newlines. Some queries may be long enough that you want to break lines; not being able to do this on natural breaks such as : can be counterintuitive.

cabo commented 1 year ago

After deciding this issue, continue in #344

cabo commented 1 year ago

2023-01-10 Interim: Do not do this. Leave S in place.