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 18:25:35 GMT
On Thu, Apr 10, 2008 at 2:10 PM, Matt Benson <> wrote:

>  Without having looked at the code, I'm not
>  understanding why [proxy] would be a "first-class"
>  dependency.  Seems like it would be optional depending
>  on whether a client of [expression?] wanted to use the
>  recording implementation.

Proxy isn't a required dependency.  You could use the existing
Expression implementations without having to record them.  However,
the recording feature is what makes this library so cool, IMHO.
Recording gives you the following benefits:

- You're using Java syntax to record what you want.
- If you change method names, you'll either get a compiler error on
your recording code or the refactoring utility will change it for you.
- Less error-prone.  If you can traverse the object graph in Java, the
builder can make an expression that can do it (aside from indexing
into arrays or using fields of course).

>  I still agree with Rahul that object graph navigation
>  is the commonality here.

Oooh, what about commons-navigator?

> But once you remove the
>  concept of an integral String representation it seems
>  like generic functor stuff to me.  JXPath has Pointers
>  that behave somewhat like what you're suggesting,
>  James, but ultimately they are still tied to the
>  original syntactic representation.  Of course, "object
>  graph navigation" is 3/4 of OGNL's name, isn't it?

Once you turn the originating syntactic representation into an
Expression object, you're free to do with it what you want.  The
syntax is hidden behind the Expression.  So, other libraries that take
Expression objects (like the one I'm going to help write for Wicket)
don't have to have any idea that you're using a String behind the
scenes (or possibly nothing but a hard-wired class that does exactly
what you did in the first place).

>  I MIGHT be able to accept the recording implementation
>  as an "expression" if you at least made the toString()
>  of the recording present something expressionlike:
>  e.g.
>  record <
>   getFoo()
>   getBar()
>   getBaz()
>  >
>  toString():  "getFoo().getBar().getBaz()"

That would be easy to do, really.  All of the recorders currently use
Proxy's idea of an InvocationRecorder which gives you a list of
RecordedInvocations.  It'd be trivial to write a toString() method
somewhere that took the method names and made a string like that out
of them (along with the parameters used along the way too).

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

View raw message