Ok I see, and agree with you. This overhead can't be hidden.
But what about change the grammar to support nested objects directly ?


On Thu, May 29, 2014 at 12:32 PM, Joe Walnes <notifications@github.com>
wrote:

> In test/filtrex-test.html:
>
> > @@ -118,6 +119,7 @@
> >      'symbols with dots': function() {
> >          eq(123, compileExpression('hello.world.foo')({'hello.world.foo': 123}));
> >          eq(123, compileExpression('order.gooandstuff')({'order.gooandstuff': 123}));
> > +        eq(123, compileExpression('hello.world.foo')({'hello':{'world':{'foo':123}}}));
>
> I would prefer flattening to be explicit, so it's easier to predict what
> "hello.world.foo" actually means.
>
> Simplest thing is to just make it an external function, so users could
> call compileExpression('a.b.c')(flatten(somedata)) if that's what they
> want. It also allows users to plug in their own flattening strategies if
> they want and doesn't add overhead for users who don't need it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/joewalnes/filtrex/pull/5/files#r13175662>.
>