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 :) - Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
