Enhanced support for filtering about json-path HOT 7 CLOSED

3. should work with the recent changes on github.
2. doesn't as JsonPath would try to read a property named "b.b-a" of the list 
object.

There are several options where we could go from here:
* Leave it as it is, you can always use the varargs method
* Always interpret dots as "path separators", however that doesn't seem to be 
what the JayWay guys want, though I'd say that dots in property names are the 
exception rather than the usual case.
* Introduce a special syntax to differentiate between a dot as path separator 
or as part of a property name (like . vs. \.)
* Add an additional parameter to JsonPath.compile that specifies how to 
interpret dots. That would have to be passed through to PathToken, 
FilterFactory and eventually to the Filter implementations.
* Differentiate between dot and array notation, that is, treat @.b.b-a as a 
this->b->b.a and @['b.b-a'] as this->b.b-a

None of the possibilities convince me entirely but after giving it some 
thought, I think I like the last one best.

Great, I will check the filter.

So if I use an array notation, the dots will be handled as path separators if 
the parameter is not between '-s. So it means we cannot mix the two things like:
@[b.'a.b'.c]
what if we say you have to put those property names between '-s what has a 
dot...
or make a hidden check can it return with a property named: 'b.b-a' if not, it 
tries to read it as a path... (you still cannot mix things here as well)

but to be honest, using dots in property names is just not fair :)

You could write @.b.['a.b'].c in that case. Of course, we'd get a problem if 
the property name also contains an apostrophe, but I guess that's a little 
far-fetched.
I thought about what you call a "hidden check" too, but I think, it's not quite 
intuitive. It would cause both {"b.b-a": "foo"} and {"b": {"b-a": "foo}} to be 
matched and you wouldn't have a way to match either one exclusively.

hm.. I still cannot get it, let's put it back to the original context:
we have these two json paths?:
$.list[?(@.b.b-a=='batext2')] --> match 2nd object in array 
$.list[?(@.['b.b-a']=='batext2')] --> match 1st object in array

so the new json is:
{"list":
  [
    {
      "a":"atext",
      "b.b-a":"batext2"
      "b":{
         "b-a":"batext",
         "b-b":"bbtext"
       }
    },
    {
      "a":"atext2",
      "b":{
         "b-a":"batext2",
         "b-b":"bbtext2"
       }
    }
  ]
}

Hopefully no one uses apostrophes in names...

that's true with the hidden check, that's why I thought to use a name match 
first, because that was the previous behavior and do the other if it cannot 
find something. But it is dirty anyway.

Oh, sorry, I got it wrong in my last comment. If we went that way, it would be 
*either* dots *or* array notation, so it would be @.b['a.b']c and not 
@.b.['a.b'].c.

Your second expression would have to read $.list[?(@['b.b-a']=='batext2')] then

Apart from that, I'd expect the same matches.

ah, ok. so if your property name has a dot you have to use bracket notation.

sounds really good 

This is supported in 0.9.0, soon to be released.