el-next@uel.java.net

Re: Should FunctionMapper be deprecated?

From: Mike Brock <cbrock_at_redhat.com>
Date: Mon, 22 Mar 2010 12:58:10 -0400

+1

This was originally one of those major limitations that really precipitated my decision to start developing MVEL. MVEL, of course, adopts plain Java-syntax for static calls, which I think makes the most amount of sense and is obviously very useful.

That said, I think it makes sense to be able to alias static methods as functions. The approach we've taken, which is probably a little too heavy-weight for the EL spec, is through the introduction of full function-pointer support at the language and runtime level. So, you're fundamentally able to do something like this:

time = System.currentTimeMillis; // reference the method
time(); // call it.

However, this has the useful side-effect of allowing you to inject functions as regular variables from the API:

Map<String, Object> vars = new HashMap<String, Object>();
vars.put("time", System.class.getMethod("currentTimeMillis"));

long time = MVEL.eval("time()", vars, Long.class);

Just food for thought.

Mike.

On 2010-03-17, at 6:39 PM, Kin-man Chung wrote:

> Current EL allows static functions to be invoked by the use of a
> FunctionMapper. See java.el package in
> http://java.sun.com/javaee/5/docs/api/
>
> For instance, if the prefix "pre" and "foo" maps to the method
> com.acme.bar.method, then the expression
>
> "#{pre:foo()}"
>
> cuases this method to be invoked.
>
> The need for both the prefix and a name, which can be unrelated
> to the actual method name, is clunky and unintuitive, and has its
> roots in JSP.
>
> Since we already allow methods in EL expressions in EL 2.2, we should
> extend this to include static methods. The most obvious syntax to use
> is to include the package name, such as
>
> "#{com.acme.bar.method())"
>
> The downside is that we are overloading the meaning of the . operator
> here, and might cause problems in parsing. There may be other ways.
>
> I'd assume we'd deprecate FunctionMapper and not include it in
> ELProcessor.
>
> -Kin-man
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>

On 2010-03-17, at 6:39 PM, Kin-man Chung wrote:

> Current EL allows static functions to be invoked by the use of a
> FunctionMapper. See java.el package in
> http://java.sun.com/javaee/5/docs/api/
>
> For instance, if the prefix "pre" and "foo" maps to the method
> com.acme.bar.method, then the expression
>
> "#{pre:foo()}"
>
> cuases this method to be invoked.
>
> The need for both the prefix and a name, which can be unrelated
> to the actual method name, is clunky and unintuitive, and has its
> roots in JSP.
>
> Since we already allow methods in EL expressions in EL 2.2, we should
> extend this to include static methods. The most obvious syntax to use
> is to include the package name, such as
>
> "#{com.acme.bar.method())"
>
> The downside is that we are overloading the meaning of the . operator
> here, and might cause problems in parsing. There may be other ways.
>
> I'd assume we'd deprecate FunctionMapper and not include it in
> ELProcessor.
>
> -Kin-man
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: el-next-unsubscribe_at_uel.dev.java.net
> For additional commands, e-mail: el-next-help_at_uel.dev.java.net
>