commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] New Expressions Sandbox Project...
Date Thu, 10 Apr 2008 12:21:26 GMT
On Thu, Apr 10, 2008 at 7:56 AM, Rahul Akolkar <rahul.akolkar@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message