+1
On Fri, Mar 26, 2010 at 11:54 AM, Mike Brock <cbrock_at_redhat.com> wrote:
> I don't really think parsing efficiency here should be the consideration. I
> think the language should be designed to come as naturally to developers as
> possible. And this is coming from a guy who prided myself on implementing
> the fastest EL parser. :)
>
> There's more than one parsing strategy to dealing with the problem in any
> case. And when I decided to take this approach in MVEL I really had to rack
> my brain to come up with a way that didn't kill parsing performance -- but
> then again, I was handwriting my parser, which is probably not appropriate
> here.
>
> Moreover, proper caching facilities should negate the need for the parse to
> happen more than once in most cases.
>
> On 2010-03-24, at 1:47 PM, Kin-man Chung wrote:
>
> >
> >
> > On 03/23/10 04:38, Martin Marinschek wrote:
> >> Hi guys,
> >>
> >> I would love to have the ability to call static functions directly -
> >> so my +1. However, I do see the parsing problems you point out,
> >> Kin-Man.
> >>
> >> How about the following: we would device a new namespace, a
> >> classpath-namespace for the Unified EL:
> >>
> >> new namespace: http://unified.el/classpath, prefix e.g. cp
> >>
> >> and then could do the following:
> >>
> >> #{cp:com.acme.functions.MyFunction()}
> >>
> >> Does that sound reasonable?
> >>
> > Reasonable, but it still needs token look-ahead during parsing.
> >
> > If we apply look-ahead to our original "natural" syntax,
> >
> > #{com.acme.Functions.myFunction()}.
> >
> > The parser can determine that "com.acme.Functions" is actually the
> > name of a "package + class", and decide that this is potentially a
> > static method invocation.
> >
> > I'll need to look a the Glassfish EL implementation to see if the
> > grammar can be easily changed to do this. For those who have
> > implemented EL before, can you also take a look, from easy of
> > implementation angle? Thanks.
> >
> > In addition, I think it'll be useful to add in the API, some kind of
> > import function. For instance,, we can have
> >
> > elProcessor.import("com.acme.Functions");
> >
> > then the static methods of this class can be used in the expression
> >
> > #{Functions.myFunctio()}
> >
> > BTW, we have exactly the same problem with Enum literals, such as
> > com.acme.Days.MONDAY, so anything we use here can also be used there!
> >
> > -Kin-man
> >
> >> Alternatively, I would say that this is an issue where annotations
> >> would definitely help to reduce the configuration clutter!
> >>
> >> And by the way, as to your remarks JSF 2: facelets also has a
> >> possibility to register EL-functions, and we use that extensively in
> >> our projects, so contrary to what you say, I think this is widely used
> >> in the JSF space.
> >>
> > I stand corrected then. In that case, FunctionMapper will not be
> > deprecated, but will coexist with new way of calling static methods.
> >
> > -Kin-man
> >
> >> best regards,
> >>
> >> Martin
> >>
> >> On 3/22/10, Mike Brock<cbrock_at_redhat.com> wrote:
> >>> +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
> >>>>
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"