On Thu, Apr 10, 2008 at 8:21 AM, James Carman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[EMAIL PROTECTED]> wrote: <snip/> > > > > (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. > <snap/>
With a bit of a disconnect. > > (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. > <snip/> Since most impls are (they generate their own parse trees etc.) and any intermediate "first-class object" simply gets in the way IMO. > > > > To summarize, generally the above abstraction has worked well. > > I didn't consider JavaScript, but that's an interesting idea. > > <snap/> Its one of the popular requests. > > (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>). > <snip/> Unconvinced, but moving on. > > (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. > <snap/> I agree, as I said its limited as-is (to bean property / object graph navigation) and not a first class expression language. Nothing against having those adapters. > > > > (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)! :) > <snip/> I'd like [expression] to have no dependencies (other than the ELs themselves, for the various adapters). > > 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. > <snap/> I think we may have sufficiently different ideas on what we need to begin playing in different sandboxes. That also means we need two component names. I do think the name [expression] would be misleading for the idea you've proposed. In fact, thats what got me thinking we wanted similar things :-) Any alternatives I could think of suggesting were a bit long for my taste, I'll keep trying. I'd like to use the [expression] for the Context+Evaluator API, which is quite a common theme in many first class expression language impls. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
