commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [DISCUSS] New Expressions Sandbox Project...
Date Fri, 11 Apr 2008 00:28:59 GMT
On Thu, Apr 10, 2008 at 1:46 PM, James Carman
<> wrote:
> On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar <> 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).

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

Yup, and [expression] doesn't convey that IMO. Thanks for being open
to finding an alternative name.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message