[DISCUSS] New Expressions Sandbox Project...

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] New Expressions Sandbox Project...

James Carman
I wanted to start up a discussion about maybe starting a new sandbox
project for expression abstraction.  It could be named
commons-expresso.  I realize that there's a J2EE framework out there
called "Expresso", but its site hasn't been updated since 2005, so I
don't know how active it is or if this would even be a conflict
anyway.  I don't really care what it's called.  I just care about the
content.

For those who have not been reading the other threads, I would like to
create a project which allows us to abstract the idea of an
"expression" in Java.  Here's the main interface:

public interface Expression
{
  public Object getValue(Object root);
  public void setValue(Object root, Object value);
}

This could be generified to perhaps:

public interface Expression<R,V>
{
  public V getValue(R root);
  public void setValue(R root, V value);
}

Anyway, the "guts" of the project would be the implementations of this
interface.  I have plans to implement it using the following
technologies for now (please add suggestions if you have them):

Javassist
MVEL
OGNL
JSTL-EL
JXPath

That's just a preliminary list, but you get the idea of the sort of
thing I'm looking for.  Matt Benson has suggested that this sort of
thing might be best suited to go into his "Morph" project currently
located at Sourceforge.  Currently, it doesn't have anything like
this.  The project would also contain expression "builder"
implementations which would allow you to use Java to build up the
expression:

public interface ExpressionBuilder<R>
{
  public R recorder();
  public <V> Expresion<R,V> buildExpression(V value);
}

Example usage:

ExpressionBuilder builder = new JavassistExpressionBuilder<Person>();
Expression<Person,String> expr =
builder.buildExpression(builder.recorder().getAddress().getCity());
Person p = ...;
String city = expr.getValue(p);

The cool thing about this is that you can switch the expression
implementation without changing how you build up the expression!
Thoughts anyone?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Antonio Petrelli
2008/4/9, James Carman <[hidden email]>:
>
> I realize that there's a J2EE framework out there
> called "Expresso", but its site hasn't been updated since 2005, so I
> don't know how active it is or if this would even be a conflict
> anyway.



There is already a regular-expression tool called Expresso:
http://www.ultrapico.com/Expresso.htm
Come on, James, express yourself better :-D

Antonio
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli
<[hidden email]> wrote:
>
>  There is already a regular-expression tool called Expresso:
>  http://www.ultrapico.com/Expresso.htm
>  Come on, James, express yourself better :-D

Thanks, Antonio.  :)  Ok, I googled only shortly to look for something
(I think I typed "expresso java" and looked at the first couple of
hits).  Again, I don't care about the name, but I do like it.  I'd go
for commons-expression (or commons-express) just as easily, though.
I'm mainly concerned with the content.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Matt Benson
In reply to this post by James Carman

--- James Carman <[hidden email]> wrote:

> I wanted to start up a discussion about maybe
> starting a new sandbox
> project for expression abstraction.  It could be
> named
> commons-expresso.  I realize that there's a J2EE
> framework out there
> called "Expresso", but its site hasn't been updated
> since 2005, so I
> don't know how active it is or if this would even be
> a conflict
> anyway.  I don't really care what it's called.  I
> just care about the
> content.
>
> For those who have not been reading the other
> threads, I would like to
> create a project which allows us to abstract the
> idea of an
> "expression" in Java.  Here's the main interface:
>
> public interface Expression
> {
>   public Object getValue(Object root);
>   public void setValue(Object root, Object value);
> }
>
> This could be generified to perhaps:
>
> public interface Expression<R,V>
> {
>   public V getValue(R root);
>   public void setValue(R root, V value);
> }
>
> Anyway, the "guts" of the project would be the
> implementations of this
> interface.  I have plans to implement it using the
> following
> technologies for now (please add suggestions if you
> have them):
>
> Javassist
> MVEL
> OGNL
> JSTL-EL
> JXPath
>
> That's just a preliminary list, but you get the idea
> of the sort of
> thing I'm looking for.  Matt Benson has suggested
> that this sort of
> thing might be best suited to go into his "Morph"
> project currently
> located at Sourceforge.

Actually, to clarify, Morph isn't "mine."  Matt
Sgarlata is the primary developer; I just came in
midway and started helping out (at least I like to
think my input has been helpful)... then, I wasn't
necessarily suggesting that new work on the expression
concept should go into Morph, either.  Actually I see
Morph being broken down into smaller pieces once we
get it into Commons.  It sounds like you're suggesting
a package similar to [proxy]/[logging]/[openpgp] whose
basic purpose is to provide a common interface over
various similar underlying technologies.  I honestly
think Morph @ Commons would ultimately have its
Language facilities removed or moved elsewhere, so
maybe there's not much overlap here beyond the idea
that your proposed project might conceivably contain
one or more built-in implementations, and one of these
might be derived from Morph's basic Language
implementation, SimpleLanguage.

> Currently, it doesn't have
> anything like
> this.  The project would also contain expression
> "builder"
> implementations which would allow you to use Java to
> build up the
> expression:
>
> public interface ExpressionBuilder<R>
> {
>   public R recorder();
>   public <V> Expresion<R,V> buildExpression(V
> value);
> }
>
> Example usage:
>
> ExpressionBuilder builder = new
> JavassistExpressionBuilder<Person>();
> Expression<Person,String> expr =
>
builder.buildExpression(builder.recorder().getAddress().getCity());
> Person p = ...;
> String city = expr.getValue(p);
>
> The cool thing about this is that you can switch the
> expression
> implementation without changing how you build up the
> expression!
> Thoughts anyone?

This would qualify as one of the built-in expression
"engines" I mentioned before, really.  So... you're
suggesting that _most_ of the "expression factory"
implementations supported by this proposition would be
built from Strings, but that it wouldn't necessarily
be so all the time?  How are you intending your
recordable implementation to be able to handle set vs.
get operations, though?  I don't get that from your
example.

-Matt

>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

sebb-2-2
In reply to this post by James Carman
On 09/04/2008, James Carman <[hidden email]> wrote:

> On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli
>  <[hidden email]> wrote:
>  >
>  >  There is already a regular-expression tool called Expresso:
>  >  http://www.ultrapico.com/Expresso.htm
>  >  Come on, James, express yourself better :-D
>
>
> Thanks, Antonio.  :)  Ok, I googled only shortly to look for something
>  (I think I typed "expresso java" and looked at the first couple of
>  hits).  Again, I don't care about the name, but I do like it.  I'd go
>  for commons-expression (or commons-express) just as easily, though.
>  I'm mainly concerned with the content.
>

Anyway, the name would be "[Apache] Commons Expresso", not just "Expresso".

>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Matt Benson
In reply to this post by James Carman

--- James Carman <[hidden email]> wrote:

> On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli
> <[hidden email]> wrote:
> >
> >  There is already a regular-expression tool called
> Expresso:
> >  http://www.ultrapico.com/Expresso.htm
> >  Come on, James, express yourself better :-D
>
> Thanks, Antonio.  :)  Ok, I googled only shortly to
> look for something
> (I think I typed "expresso java" and looked at the
> first couple of
> hits).  Again, I don't care about the name, but I do
> like it.  I'd go
> for commons-expression (or commons-express) just as
> easily, though.
> I'm mainly concerned with the content.

I'm not convinced that, once you remove the constraint
of a String representation, that what you are talking
about is necessarily an "expression".  Also given the
concern I brought up about recording, explicitly
calling getters doesn't AFAICT obviously yield a
result that knows how to accomplish a setValue.

-Matt

>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
In reply to this post by Matt Benson
On Wed, Apr 9, 2008 at 10:24 AM, Matt Benson <[hidden email]> wrote:
>  Actually, to clarify, Morph isn't "mine."  Matt
>  Sgarlata is the primary developer; I just came in
>  midway and started helping out (at least I like to
>  think my input has been helpful)... then, I wasn't
>  necessarily suggesting that new work on the expression
>  concept should go into Morph, either.
I apologize.  I thought the project was yours.  My mistake.

>  This would qualify as one of the built-in expression
>  "engines" I mentioned before, really.  So... you're
>  suggesting that _most_ of the "expression factory"
>  implementations supported by this proposition would be
>  built from Strings, but that it wouldn't necessarily
>  be so all the time?  How are you intending your
>  recordable implementation to be able to handle set vs.
>  get operations, though?  I don't get that from your
>  example.
>

Yes, most of them would be based on Strings (we'd probably have a
superclass for string-based expressions).  But, Javassist would
actually generate a class at runtime to evaluate the expression.  As
for how we provide "set" operations, the "recorder" basically records
what you have done, what methods you called and their parameters.
Then, the builder looks at that information and figures out how to
build up the expression so that it's "settable."  Ognl provides this
sort of thing out of the box (see the Ognl.setValue method I think
it's called); the string basically points to a value and you can use
that string to set/get either way.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Antonio Petrelli
In reply to this post by sebb-2-2
2008/4/9, sebb <[hidden email]>:

>
> On 09/04/2008, James Carman <[hidden email]> wrote:
> > On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli
> >  <[hidden email]> wrote:
> >  >
> >  >  There is already a regular-expression tool called Expresso:
> >  >  http://www.ultrapico.com/Expresso.htm
> >  >  Come on, James, express yourself better :-D
> >
> >
> > Thanks, Antonio.  :)  Ok, I googled only shortly to look for something
> >  (I think I typed "expresso java" and looked at the first couple of
> >  hits).  Again, I don't care about the name, but I do like it.  I'd go
> >  for commons-expression (or commons-express) just as easily, though.
> >  I'm mainly concerned with the content.
> >
>
>
> Anyway, the name would be "[Apache] Commons Expresso", not just
> "Expresso".



It doesn't matter, at Tiles we were refused the name of "Dimensions" for
"Apache Tiles Dimensions" because Dimensions is already a piece of software.
We needed to rename it (FYI it is "Kaolin").

Antonio
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
In reply to this post by Matt Benson
On Wed, Apr 9, 2008 at 10:28 AM, Matt Benson <[hidden email]> wrote:
>  I'm not convinced that, once you remove the constraint
>  of a String representation, that what you are talking
>  about is necessarily an "expression".  Also given the
>  concern I brought up about recording, explicitly
>  calling getters doesn't AFAICT obviously yield a
>  result that knows how to accomplish a setValue.
>

Yes, the "builder" would be somewhat limited.  It wouldn't allow you
to build expressions for stuff like indexing into arrays or other more
complex situations, but it would cover the simple property traversal
situations.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Martin Cooper-3
In reply to this post by James Carman
On Wed, Apr 9, 2008 at 7:18 AM, James Carman <[hidden email]>
wrote:

> On Wed, Apr 9, 2008 at 10:12 AM, Antonio Petrelli
> <[hidden email]> wrote:
> >
> >  There is already a regular-expression tool called Expresso:
> >  http://www.ultrapico.com/Expresso.htm
> >  Come on, James, express yourself better :-D
>
> Thanks, Antonio.  :)  Ok, I googled only shortly to look for something
> (I think I typed "expresso java" and looked at the first couple of
> hits).  Again, I don't care about the name, but I do like it.  I'd go
> for commons-expression (or commons-express) just as easily, though.
> I'm mainly concerned with the content.


The Commons rule is (or at least was) that Commons components should have
"boring functional names", so Commons Expression would fit, but Commons
Expresso would not. (Yes, there are some components that do not conform, but
they existed prior to the instigation of the rule.)

--
Martin Cooper



>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Wed, Apr 9, 2008 at 10:34 AM, Martin Cooper <[hidden email]> wrote:
>  The Commons rule is (or at least was) that Commons components should have
>  "boring functional names", so Commons Expression would fit, but Commons
>  Expresso would not. (Yes, there are some components that do not conform, but
>  they existed prior to the instigation of the rule.)
>

No big deal.  What's in a name?  That which we call a rose by any
other name would smell as sweet!  Ooooh!  I've got it!  How about
comons-rose? ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
In reply to this post by Matt Benson
On Wed, Apr 9, 2008 at 10:28 AM, Matt Benson <[hidden email]> wrote:
>  I'm not convinced that, once you remove the constraint
>  of a String representation, that what you are talking
>  about is necessarily an "expression".  Also given the
>  concern I brought up about recording, explicitly
>  calling getters doesn't AFAICT obviously yield a
>  result that knows how to accomplish a setValue.
>

Also, what I'm proposing would be in the sandbox, so maybe I can get
some code in there so that we can look at it.  If we don't like it, we
can remove it or make it dormant.  I just wanted to make sure that the
idea of the project doesn't go against the charter.  I guess in the
strictest sense, it does, since it's somewhat of a "framework."  Then
again, so is proxy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Matt Benson
In reply to this post by James Carman
Excuse the top post, but there isn't much context to
what I want to say.

Beyond what I've already said wrt Morph, its Language
concept does allow for setting and getting from
expressions, as do those various libraries to which
James plans to interface.  But Morph also contains a
Reflector abstraction, which I have suggested is
suited to be a discrete Commons component.  Morph
implements a Language with a Reflector.  The only
difference between the two is that a Reflector is
intended to set/get a property exactly one level
removed from the source object.  Perhaps that is an
unnecessary distinction and the [expression] idea is
really another way of expressing the need for generic
reflectors that can get/set a -possibly nested-
property given a root object (BeanUtils and Spring
have also implemented this basic requirement as well).
 I don't think this POV invalidates Morph's existing
single-level Reflectors, nor do I see any real
conflict with "complex" Reflectors being dependent on
"simple" Reflectors.

To address the other part of your proposal, James, the
record/playback  mechanism:  wouldn't the resulting
object be a functor a la [functor]?  A get would be a
function, a set a procedure.

-Matt

--- James Carman <[hidden email]> wrote:

> I wanted to start up a discussion about maybe
> starting a new sandbox
> project for expression abstraction.  It could be
> named
> commons-expresso.  I realize that there's a J2EE
> framework out there
> called "Expresso", but its site hasn't been updated
> since 2005, so I
> don't know how active it is or if this would even be
> a conflict
> anyway.  I don't really care what it's called.  I
> just care about the
> content.
>
> For those who have not been reading the other
> threads, I would like to
> create a project which allows us to abstract the
> idea of an
> "expression" in Java.  Here's the main interface:
>
> public interface Expression
> {
>   public Object getValue(Object root);
>   public void setValue(Object root, Object value);
> }
>
> This could be generified to perhaps:
>
> public interface Expression<R,V>
> {
>   public V getValue(R root);
>   public void setValue(R root, V value);
> }
>
> Anyway, the "guts" of the project would be the
> implementations of this
> interface.  I have plans to implement it using the
> following
> technologies for now (please add suggestions if you
> have them):
>
> Javassist
> MVEL
> OGNL
> JSTL-EL
> JXPath
>
> That's just a preliminary list, but you get the idea
> of the sort of
> thing I'm looking for.  Matt Benson has suggested
> that this sort of
> thing might be best suited to go into his "Morph"
> project currently
> located at Sourceforge.  Currently, it doesn't have
> anything like
> this.  The project would also contain expression
> "builder"
> implementations which would allow you to use Java to
> build up the
> expression:
>
> public interface ExpressionBuilder<R>
> {
>   public R recorder();
>   public <V> Expresion<R,V> buildExpression(V
> value);
> }
>
> Example usage:
>
> ExpressionBuilder builder = new
> JavassistExpressionBuilder<Person>();
> Expression<Person,String> expr =
>
builder.buildExpression(builder.recorder().getAddress().getCity());

> Person p = ...;
> String city = expr.getValue(p);
>
> The cool thing about this is that you can switch the
> expression
> implementation without changing how you build up the
> expression!
> Thoughts anyone?
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Wed, Apr 9, 2008 at 3:01 PM, Matt Benson <[hidden email]> wrote:
>  To address the other part of your proposal, James, the
>  record/playback  mechanism:  wouldn't the resulting
>  object be a functor a la [functor]?  A get would be a
>  function, a set a procedure.
>

Yes, they would, and I was planning on providing adapters to that
effect.  I wouldn't necessarily code to the functor API, but you could
use the Expression object as a function by wrapping it with the
adapter class.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
In reply to this post by Matt Benson
On Wed, Apr 9, 2008 at 3:01 PM, Matt Benson <[hidden email]> wrote:

> Excuse the top post, but there isn't much context to
>  what I want to say.
>
>  Beyond what I've already said wrt Morph, its Language
>  concept does allow for setting and getting from
>  expressions, as do those various libraries to which
>  James plans to interface.  But Morph also contains a
>  Reflector abstraction, which I have suggested is
>  suited to be a discrete Commons component.  Morph
>  implements a Language with a Reflector.  The only
>  difference between the two is that a Reflector is
>  intended to set/get a property exactly one level
>  removed from the source object.  Perhaps that is an
>  unnecessary distinction and the [expression] idea is
>  really another way of expressing the need for generic
>  reflectors that can get/set a -possibly nested-
>  property given a root object (BeanUtils and Spring
>  have also implemented this basic requirement as well).
>   I don't think this POV invalidates Morph's existing
>  single-level Reflectors, nor do I see any real
>  conflict with "complex" Reflectors being dependent on
>  "simple" Reflectors.
>
>  To address the other part of your proposal, James, the
>  record/playback  mechanism:  wouldn't the resulting
>  object be a functor a la [functor]?  A get would be a
>  function, a set a procedure.
>

So, does anyone object to me putting this code into the sandbox?  I've
got working versions of expressions and builders (with test cases of
course) for:

MVEL
OGNL
BeanUtils
JXPath

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Wed, Apr 9, 2008 at 9:47 PM, James Carman <[hidden email]> wrote:
>  So, does anyone object to me putting this code into the sandbox?  I've
>  got working versions of expressions and builders (with test cases of
>  course) for:
>
>  MVEL
>  OGNL
>  BeanUtils
>  JXPath
>

If you're interested, I set it up in my own SVN repository while I was
working on it:

http://svn.carmanconsulting.com/public/commons-expression/trunk

Enjoy!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Rahul Akolkar
On Wed, Apr 9, 2008 at 11:18 PM, James Carman
<[hidden email]> wrote:
> On Wed, Apr 9, 2008 at 9:47 PM, James Carman <[hidden email]> wrote:
> >  So, does anyone object to me putting this code into the sandbox?
<snip/>

No, I support this and would like to work on it.


> >  I've
> >  got working versions of expressions and builders (with test cases of
> >  course) for:
> >
> >  MVEL
> >  OGNL
> >  BeanUtils
> >  JXPath
> >
>
> If you're interested, I set it up in my own SVN repository while I was
> working on it:
>
> http://svn.carmanconsulting.com/public/commons-expression/trunk
>
<snap/>

Thanks a lot, this is great. I was lost reading the emails in this
thread but the code has made things much clearer.

I have some immediate comments:

(1) The proposed API feels like [objectgraphnavigation] rather than
[expression], which is an interesting subset of expressions, but
limiting nevertheless. I'm interested in the latter, and also think it
makes the former redundant.

(2) I'd like to claim that [expression] is a solved problem ;-)
[scxml] requires pluggable expression languages and already has an
abstraction over ELs:

  http://commons.apache.org/scxml/guide/contexts-evaluators.html

The core of [expression] should consist of two interfaces (I'm happy
to do this by cleaning up the corresponding bits in [scxml]):

public interface Context {
  Object get(String name);
  void set(String name, Object value);
}

public interface Evaluator {
  Object evaluate(String expression, Context context)
         throws EvaluationException;
  Context newContext(Context parent);
}

Names TBD etc.

SAMPLE USAGE (untested, ofcourse):

  Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example

  Context context = evaluator.newContext(null);
  context.put(...);

  try {
    /*Some type*/ result = evaluator.evaluate("...", context);
  } catch (EvaluationExpression ee) {
    // ...
  }

We have proven implementations of this in [scxml] land for:
 * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
 * Commons JEXL
 * JavaScript (by way of Rhino)
 * Various (by way of javax.script)
 * Pnuts

Other comments:
 * I've done adapters for two proprietary ELs
 * MVEL would be trivial
 * I'm not familiar with its OGNL APIs, will take a look later

To summarize, generally the above abstraction has worked well.

(3) Generics don't buy us much in terms of type safety / correctness
guarantees for [expression]. Lets not use them (easier to support 1.4
that way, for example).

(4) I don't think of BeanUtils as an expression language, or JXPath
for that matter (relates to point 1 above a bit). That doesn't mean
there can't be corresponding Evaluator implementations, just means
users of those implementations will need to understand the limitations
(and we will need to document them). For example, don't ask the
BeanUtils evaluator to evaluate "22 / 7".

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

I suggest we use the interfaces above, I can bootstrap [expression] in
the sandbox per those.

-Rahul


> Enjoy!
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[hidden email]> wrote:
>  No, I support this and would like to work on it.
>

That's great!  I would love to have some help/input on this.

>  Thanks a lot, this is great. I was lost reading the emails in this
>  thread but the code has made things much clearer.
>
>  I have some immediate comments:
>
>  (1) The proposed API feels like [objectgraphnavigation] rather than
>  [expression], which is an interesting subset of expressions, but
>  limiting nevertheless. I'm interested in the latter, and also think it
>  makes the former redundant.
>

Yes, primarily it deals with object graph navigation, but the
Expression implementations can support more complex scenarios via the
underlying technology.

>  (2) I'd like to claim that [expression] is a solved problem ;-)
>  [scxml] requires pluggable expression languages and already has an
>  abstraction over ELs:
>
>   http://commons.apache.org/scxml/guide/contexts-evaluators.html
>
>  The core of [expression] should consist of two interfaces (I'm happy
>  to do this by cleaning up the corresponding bits in [scxml]):
>
>  public interface Context {
>   Object get(String name);
>   void set(String name, Object value);
>  }
>
>  public interface Evaluator {
>   Object evaluate(String expression, Context context)
>          throws EvaluationException;
>   Context newContext(Context parent);
>  }

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.

>
>  Names TBD etc.
>
>  SAMPLE USAGE (untested, ofcourse):
>
>   Evaluator evaluator = new JexlEvaluator(); // Use JEXL, for example
>
>   Context context = evaluator.newContext(null);
>   context.put(...);
>
>   try {
>     /*Some type*/ result = evaluator.evaluate("...", context);
>   } catch (EvaluationExpression ee) {
>     // ...
>   }
>
>  We have proven implementations of this in [scxml] land for:
>   * EL (JSP 2.0 and a variant with a bit of JSF MBEs thrown in as well)
>   * Commons JEXL
>   * JavaScript (by way of Rhino)
>   * Various (by way of javax.script)
>   * Pnuts
>
>  Other comments:
>   * I've done adapters for two proprietary ELs
>   * MVEL would be trivial
>   * I'm not familiar with its OGNL APIs, will take a look later
>
>  To summarize, generally the above abstraction has worked well.

I didn't consider JavaScript, but that's an interesting idea.
>
>  (3) Generics don't buy us much in terms of type safety / correctness
>  guarantees for [expression]. Lets not use them (easier to support 1.4
>  that way, for example).
>

I would have to disagree with this.  The API I'm using makes the code
easier to read, IMHO.  I would want it to use generics.  No, it
doesn't necessarily *guarantee* type safety (as evidenced by the
@SuppressWarnings("unchecked) in the code), but it doesn't hurt by
having it there and makes it easier to use the code in other libraries
(like Wicket; I can imagine a Wicket ExpressionModel<T> which extends
IModel<T>).

>  (4) I don't think of BeanUtils as an expression language, or JXPath
>  for that matter (relates to point 1 above a bit). That doesn't mean
>  there can't be corresponding Evaluator implementations, just means
>  users of those implementations will need to understand the limitations
>  (and we will need to document them). For example, don't ask the
>  BeanUtils evaluator to evaluate "22 / 7".

BeanUtils does support "expressions" in that they have their own
expression syntax for referring to bean properties.  That's why I
chose to support it.  The same goes for JXPath.

>
>  (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)! :)

>  I suggest we use the interfaces above, I can bootstrap [expression] in
>  the sandbox per those.
>

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

Rahul Akolkar
On Thu, Apr 10, 2008 at 8:21 AM, James Carman
<[hidden email]> wrote:
> On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <[hidden email]> wrote:
<snip/>

> >
> >  (1) The proposed API feels like [objectgraphnavigation] rather than
> >  [expression], which is an interesting subset of expressions, but
> >  limiting nevertheless. I'm interested in the latter, and also think it
> >  makes the former redundant.
> >
>
> Yes, primarily it deals with object graph navigation, but the
> Expression implementations can support more complex scenarios via the
> underlying technology.
>
<snap/>

With a bit of a disconnect.


> >  (2) I'd like to claim that [expression] is a solved problem ;-)
> >  [scxml] requires pluggable expression languages and already has an
> >  abstraction over ELs:
> >
> >   http://commons.apache.org/scxml/guide/contexts-evaluators.html
> >
> >  The core of [expression] should consist of two interfaces (I'm happy
> >  to do this by cleaning up the corresponding bits in [scxml]):
> >
> >  public interface Context {
> >   Object get(String name);
> >   void set(String name, Object value);
> >  }
> >
> >  public interface Evaluator {
> >   Object evaluate(String expression, Context context)
> >          throws EvaluationException;
> >   Context newContext(Context parent);
> >  }
>
> 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.


> >
> >  To summarize, generally the above abstraction has worked well.
>
> I didn't consider JavaScript, but that's an interesting idea.
> >
<snap/>

Its one of the popular requests.


> >  (3) Generics don't buy us much in terms of type safety / correctness
> >  guarantees for [expression]. Lets not use them (easier to support 1.4
> >  that way, for example).
> >
>
> I would have to disagree with this.  The API I'm using makes the code
> easier to read, IMHO.  I would want it to use generics.  No, it
> doesn't necessarily *guarantee* type safety (as evidenced by the
> @SuppressWarnings("unchecked) in the code), but it doesn't hurt by
> having it there and makes it easier to use the code in other libraries
> (like Wicket; I can imagine a Wicket ExpressionModel<T> which extends
> IModel<T>).
>
<snip/>

Unconvinced, but moving on.


> >  (4) I don't think of BeanUtils as an expression language, or JXPath
> >  for that matter (relates to point 1 above a bit). That doesn't mean
> >  there can't be corresponding Evaluator implementations, just means
> >  users of those implementations will need to understand the limitations
> >  (and we will need to document them). For example, don't ask the
> >  BeanUtils evaluator to evaluate "22 / 7".
>
> BeanUtils does support "expressions" in that they have their own
> expression syntax for referring to bean properties.  That's why I
> chose to support it.  The same goes for JXPath.
>
<snap/>

I agree, as I said its limited as-is (to bean property / object graph
navigation) and not a first class expression language. Nothing against
having those adapters.


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


> >  I suggest we use the interfaces above, I can bootstrap [expression] in
> >  the sandbox per those.
> >
>
> 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.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] New Expressions Sandbox Project...

James Carman
On Thu, Apr 10, 2008 at 12:12 PM, Rahul Akolkar <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12