Missing test case for 2+ '&&' operartors in filter

[jarangutan]

What is

Hello o/

Using the library theory/jsonpath: RFC 9535 JSONPath in Go for Golang, I came across a potential implementation issue when using two or more '&&' operators in a filter.

The query looked like:
$.store.book[? @.category == "reference" && @.author == "Nigel Rees" && @.price == 8.95]

The way to get past this issue in that implementation was to do something like this:
$.store.book[? @.category == "reference" && (@.author == "Nigel Rees" && @.price == 8.95)]

If you needed more '&&' conditions, you would end up doing:

$.store.book[? @.category == "reference" && (@.author == "Nigel Rees" && (@.price == 8.95 && @.title == "Sayings of the Century")) ]

What do

I wanted to check in before opening a PR if that issue with two '&&'s is expected RFC behavior or not. From messing with a few other RFC9535 implementations, it seems like you should be able to do multiple '&&'s same you can do multiple '||'.

Theory in the issue linked peeked at the Rust version he based his Go implementation off of and noted the rust version did handle 2+ '&&'s. He also noted seeing this oddness but thought it was inherent to the RFC.

If the behavior is to allow multiple &&s, I can add a few test cases to help cover it o/

[taimoorzaeem]

According to RFC, we have grammar:

logical-and-expr    = basic-expr *(S "&&" S basic-expr)
                        ; conjunction
                        ; binds more tightly than disjunction

basic-expr          = paren-expr /
                      comparison-expr /
                      test-expr

paren-expr          = [logical-not-op S] "(" S logical-expr S ")"
                                        ; parenthesized expression
logical-not-op      = "!"               ; logical NOT operator

This clearly means that multiple && filter expressions like [?@a && @b && @c] should be supported without explicit brackets. My implementation also supports this. Adding tests to cover this would be great 👍

[jarangutan]

Resolved with #112