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.
Kin-man
> Mark
>