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. > > > > 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]
