I seem to be having this conversation a lot recently, but, in this case,
import functions more like an alias, right?
I'm not opposed to supporting this functionality, but I don't think import
is the right word to use; hence, alias.
What do you think?
--Lincoln
On Fri, Mar 26, 2010 at 2:21 PM, Kin-man Chung <Kin-Man.Chung_at_sun.com>wrote:
> 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
>>
>>
> ---------------------------------------------------------------------
> 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"