commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject Re: [DISCUSS] New Expressions Sandbox Project...
Date Fri, 11 Apr 2008 01:38:35 GMT
On Thu, Apr 10, 2008 at 8:28 PM, Rahul Akolkar <> wrote:
>  > 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 really think being able to encapsulate these ideas is beneficial
(and makes this stuff more reusable).  Of course, allowing these
things to be serialized is important too (for web components that need
to be stored in the HTTP session such as in Wicket for example).

I pinged Jesse Kuhnert today to ask him about it (the current API).
He confirmed that it's not currently supported, but I asked if it
could be.

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

No problem at all!  As I've said before, I'm not all about the name
and I agree with you that I don't necessarily want to tie up a name
like "expression" since it could be used for a library which provides
a more complete abstraction of expression languages.  This is somewhat
like picking a keyword for a programming language.  We have to be

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

View raw message