On 08/04/11 22:01, Ramesh wrote:
> Not sure if accessing the static fields is required.
> But if it is required, this syntax sound good.
This not just about the static fields. We can use it for static methods
too, and that'll let us use static functions directly in EL, without
having to define them first (as we have proposed in ELProcessor). Like
#{"T(java.lang.Class).forName("MyClass")}
Of if we predefine the package "java.lang.*", we can write the above as
#{T(Class).forName("MyClass")}
A syntax for a class is going to be very useful in other area too. The
same syntax can also be used for referencing Enum constants, since they
behave like a static fields. Also, I am thinking ahead about how to add
constructors in EL, just to give you hints about what to come next. :-)
Kin-man
>
> On 8/5/2011 4:42 AM, 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.
>>
>> Kin-man
>>