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 Thu, 10 Apr 2008 17:46:19 GMT
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).

>  > >
>  > >  (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:
For additional commands, e-mail:

View raw message