On 08/05/11 13:32, Mark Thomas wrote:
> On 05/08/2011 19:16, Kin-man Chung wrote:
>
>> On 08/05/11 10:04, Mark Thomas wrote:
>>
>>> On 05/08/2011 17:48, Kin-man Chung wrote:
>>>
>>>
>>>> On 08/05/11 02:14, Mark Thomas wrote:
>>>>
>>>>
>>>>> On 05/08/2011 00:12, Kin-man Chung wrote:
>>>>>
>>>>>
>>>>>
>>>>>> One of the proposed features for this JSR is the inclusion of static
>>>>>> fields in EL expressions. The Java syntax for static fields (e.g.
>>>>>> "a.b.MyClass.field") is in direct conflict with the EL dot ('.')
>>>>>> operator and using that syntax in EL would introduce an ambiguity at
>>>>>> parse time. It has been suggested before that we keep the
>>>>>> ambiguity at
>>>>>> parse time, and use an ELResolver to resolve it run evaluation time.
>>>>>>
>>>>>> Instead of pursuing such idea, I'd like to use another idea from
>>>>>> Spring
>>>>>> EL, which uses the notation T() to denote a type. So to reference a
>>>>>> static field one would write, for instance,
>>>>>>
>>>>>> #{"T(java.lang.System).out"}
>>>>>>
>>>>>> Spring EL also use T() to specify an instance of Class, but I think it
>>>>>> overloads its meaning unnecessarily, when one can use T().class to do
>>>>>> the same thing. But this is just an aside.
>>>>>>
>>>>>> I think this is a very good compromise. It is simpler to implement
>>>>>> and
>>>>>> should lead to better performance.
>>>>>>
>>>>>> Please tell me what you think, before I go and work out all the
>>>>>> details
>>>>>> in the spec. :-) Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>> My only concern would be if this introduced other ambiguities. I don't
>>>>> see any so +1 from me.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> The only ambiguity I see is the id "T", since T() can be taken to mean a
>>>> function call. We may have to make T a reserved word. Hmm...
>>>>
>>>>
>>> It is just another operator. I couldn't see a problem with that.
>>>
>>>
>>>
>> Making T a reserved word prevents an user from doing things like
>>
>> elManager.defineFunction("", "T", myFunction);
>> elProcessor.getValue("#{T()}); // ambiguity here!
>>
>> BTW, all operators that looks like an<id> are all reserved. Examples:
>> "not", "and" etc. Making it reserved makes parsers easier.
>>
> Sorry, I meant I didn't see a problem with making it reserved.
>
>
Ah, I misunderstood. :-)
> Mark
>