I weren't worry about parsing efficiency, but more about feasibility.
I should take a closer look at MVEL, but I gather that it uses the
syntax #{com.acme.Functions.myFunc()} for static methods, and that
it is not too hard to implement.
Talking about hande-written parser vs. javacc. It has brought to
my attention that javacc generates non-performant codes, especially
in areas of buffer allocations and the need to turn String to stream
and back to String again. Is this your experience?
Ah I digress. So we seem to agree that we should use the syntax
#{com.acme.Functions,myFunc()}
for static method calls. What about the import functionality
in API? It is useful as a shorthand?
Kin-man
On 03/26/10 08:54, Mike Brock 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
>