commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Horsman <>
Subject Re: [PATCH] Re: [jexl] - checking for unresolved variables
Date Mon, 12 Jan 2004 19:47:21 GMT
On Mon, 2004-01-12 at 16:28, Geir Magnusson Jr wrote:

> To be clear, I *really* don't think it's a good idea to break usage.  

That sounds reasonable. It's a judgement call on when it's a good time
to break backwards compatibility and I don't know enough about Jexl.

> Now, I certainly agree that this would be darn useful, and I see two 
> ways (offhand) to approach it :
> 1) Your solution, where the context implementation has to understand 
> and know about all this magic jexl stuff

Not quite. in my solution the context is actually pretty stupid. It just
throws an exception when it's asked something it doesn't know.

> Initial comments - you need to be sure that you don't get fooled by a 
> sequence of expressions that will resolve ok - IOW, an assignment
>     a = b;
> w/ 'b' in the context should result in 'OK' for an unresolved check 
> even though a isn't in the context to start.

I didn't realise you could do that. But by happy coincidence my solution
does cope with that. The JexlContext is never asked for the value of "a"
so it doesn't complain.

> The other would be to have a checker  that takes an expression and 
> figures out if it will go given a context.  That leads to a two step 
> execution process, where you'd first run the check and then 
> evaluate()....

I like this idea. Sounds more complicated to code but could be worth it.
It would be cool to provide other information too. Like, give me a list
of all the unknown variables (not just the first one you came across).
Or, give me a list of all the variables used in this expression.

One thing occurs to me. If we do end up holding some state during the
checking process then we have to make sure that it is thread safe. I can
see the same JexlContext being applied to different Expressions and the
same Expression being passed different JexlContexts. 

I remain, as ever, open minded :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message