commons-dev mailing list archives

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


Mime
View raw message