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