On Thu, Apr 10, 2008 at 1:46 PM, 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). > <snip/>
Makes sense, its worthwhile to have an opportunity to store compiled forms. I was just looking at the OGNL API, I'm not sure about the root object either. > > > > > > 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). > <snap/> Yup, and [expression] doesn't convey that IMO. Thanks for being open to finding an alternative name. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
