We need the parser to implement at least some of the sugar syntax variants. In some areas this will need quite some refactoring of the existing parsers but other areas should be easy.
[ ] & instead of and() (maybe , should do this as per spec as well)
[ ] | instead of or()
[ ] name=val instead of eq(name,val)
[ ] count=lt=10 instead of lt(count,10)
[ ] name=val&count=1 instead of eq(name,val),eq(count,1)
[ ] () based arrays (ie. foo=in=(3,bar,true,2000-01-01T00:00:00Z)
[ ] typecasting (ie foo=string:3)
[ ] array nesting: (foo,bar)=3 instead of eq(foo.bar,3)
[ ] array nesting: foo/bar=3 instead of eq(foo.bar,3)
This listing is neither complete neither do I expect us to implement all of it. We'll close this as soon as we reach some kind of consensus that what's implemented is easy enough.
We need the parser to implement at least some of the sugar syntax variants. In some areas this will need quite some refactoring of the existing parsers but other areas should be easy.
&
instead ofand()
(maybe,
should do this as per spec as well)|
instead ofor()
name=val
instead ofeq(name,val)
count=lt=10
instead oflt(count,10)
name=val&count=1
instead ofeq(name,val),eq(count,1)
()
based arrays (ie.foo=in=(3,bar,true,2000-01-01T00:00:00Z)
foo=string:3
)(foo,bar)=3
instead ofeq(foo.bar,3)
foo/bar=3
instead ofeq(foo.bar,3)
This listing is neither complete neither do I expect us to implement all of it. We'll close this as soon as we reach some kind of consensus that what's implemented is easy enough.