--- James Carman <[EMAIL PROTECTED]> wrote: > On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar > <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > The first-class Expression object encapsulates the > specifics of the > implementation (whether it be a String or some > Serializable object or > whatever). This way, you just code to the > commons-expression API > (getValue/setValue) rather than carrying around some > string. Also, > the implementations are free to "compile" their > expressions so that > they perform better (the MVEL implementation does > this and it smokes > all of the others in my simple benchmarking, because > I can't get OGNL > to compile its expression without a "root object" > from the beginning). > > > > > > > > > (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). > > Well, the builder idea can't be done without using > proxies. And, you > can't do the type of proxies necessary for the > majority of cases (ones > that extend classes rather than implement > interfaces) using the JDK > proxy support only. So, you're going to have to > have a dependency > there somewhere (assuming you like the Builder > idea). I'd rather use > Proxy for this since that's its job. It knows how > to make proxies > using various technologies and I don't want to have > to think about > that in this library. Proxy doesn't have any > required dependencies > out of the box. It would, of course, require > dependencies based on > which proxying technology you choose to use in your > builders.
Without having looked at the code, I'm not understanding why [proxy] would be a "first-class" dependency. Seems like it would be optional depending on whether a client of [expression?] wanted to use the recording implementation. I still agree with Rahul that object graph navigation is the commonality here. But once you remove the concept of an integral String representation it seems like generic functor stuff to me. JXPath has Pointers that behave somewhat like what you're suggesting, James, but ultimately they are still tied to the original syntactic representation. Of course, "object graph navigation" is 3/4 of OGNL's name, isn't it? I MIGHT be able to accept the recording implementation as an "expression" if you at least made the toString() of the recording present something expressionlike: e.g. record < getFoo() getBar() getBaz() > toString(): "getFoo().getBar().getBaz()" -Matt > > > > > > > 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. > > If people feel that [expression] isn't the right > name for what I've > come up with, I don't really care (as I said, what's > in a name). But, > the idea of an expression just fit in my mind. I'll > try to come up > with something else if you're really that opposed to > me using the name > "expression". The term "macro" came to mind when I > was thinking about > a name for this thing, since the builders are > essentially recording > something from the user (on a proxy) that will later > be played back > (on some other object). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
