On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > No, I support this and would like to work on it. >
That's great! I would love to have some help/input on this. > Thanks a lot, this is great. I was lost reading the emails in this > thread but the code has made things much clearer. > > I have some immediate comments: > > (1) The proposed API feels like [objectgraphnavigation] rather than > [expression], which is an interesting subset of expressions, but > limiting nevertheless. I'm interested in the latter, and also think it > makes the former redundant. > Yes, primarily it deals with object graph navigation, but the Expression implementations can support more complex scenarios via the underlying technology. > (2) I'd like to claim that [expression] is a solved problem ;-) > [scxml] requires pluggable expression languages and already has an > abstraction over ELs: > > http://commons.apache.org/scxml/guide/contexts-evaluators.html > > The core of [expression] should consist of two interfaces (I'm happy > to do this by cleaning up the corresponding bits in [scxml]): > > public interface Context { > Object get(String name); > void set(String name, Object value); > } > > public interface Evaluator { > Object evaluate(String expression, Context context) > throws EvaluationException; > Context newContext(Context parent); > } I don't know about this API. The idea behind [expression] is that it's not necessarily string-based (a lot of the impls are, but the Javassist one wouldn't be; it'll probably only be available via builder). The [expression] project strives to treat the expression as a first-class object which encapsulates the underlying technology. > > Names TBD etc. > > SAMPLE USAGE (untested, ofcourse): > > Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example > > Context context = evaluator.newContext(null); > context.put(...); > > try { > /*Some type*/ result = evaluator.evaluate("...", context); > } catch (EvaluationExpression ee) { > // ... > } > > We have proven implementations of this in [scxml] land for: > * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well) > * Commons JEXL > * JavaScript (by way of Rhino) > * Various (by way of javax.script) > * Pnuts > > Other comments: > * I've done adapters for two proprietary ELs > * MVEL would be trivial > * I'm not familiar with its OGNL APIs, will take a look later > > To summarize, generally the above abstraction has worked well. I didn't consider JavaScript, but that's an interesting idea. > > (3) Generics don't buy us much in terms of type safety / correctness > guarantees for [expression]. Lets not use them (easier to support 1.4 > that way, for example). > I would have to disagree with this. The API I'm using makes the code easier to read, IMHO. I would want it to use generics. No, it doesn't necessarily *guarantee* type safety (as evidenced by the @SuppressWarnings("unchecked) in the code), but it doesn't hurt by having it there and makes it easier to use the code in other libraries (like Wicket; I can imagine a Wicket ExpressionModel<T> which extends IModel<T>). > (4) I don't think of BeanUtils as an expression language, or JXPath > for that matter (relates to point 1 above a bit). That doesn't mean > there can't be corresponding Evaluator implementations, just means > users of those implementations will need to understand the limitations > (and we will need to document them). For example, don't ask the > BeanUtils evaluator to evaluate "22 / 7". BeanUtils does support "expressions" in that they have their own expression syntax for referring to bean properties. That's why I chose to support it. The same goes for JXPath. > > (5) The [proxy] APIs have bled into your proposal. While thats > completely understandable in a PoC since you have the [proxy] usecase > in mind, we will have to clean that up. Perhaps [proxy] or [scxml] > might need a subinterface or equivalent of the cleaner [expression] > APIs, we'll have to see. If [expression] makes progress, I'd want > [scxml] to depend on it. > Well, the builder idea does require proxies to get it to work. I'm using the InvocationRecorder support from Proxy to achieve this. I could pull that stuff out of proxy and into [expression] if others see that as necessary. I think the builder idea is a very nice addition, though. It's like being able to create an anonymous inner class in Java without having to create the class. It's almost like having a closure (albeit a limited one)! :) > I suggest we use the interfaces above, I can bootstrap [expression] in > the sandbox per those. > I can put my existing code into the sandbox to bootstrap it. I have access to the sandbox. I just wanted to make sure nobody completely objected to the idea behind [expression] with respect to the commons in general. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
