On 08/08/11 03:35, Pete Muir wrote:
> On 5 Aug 2011, at 21:57, Kin-man Chung wrote:
>
>
>> While working on static fields, I was thinking about importing classes so that you can write
>>
>> #{T(Boolean).TRUE}
>>
>> instead of
>>
>> #{T(java.lang.Boolean).TRUE}
>>
>> and a method in ELManager to do that:
>>
>> public void importClass(String className);
>>
>> e.g. elManager.importClass("java.lang.Boolean");
>>
>> I would like to also allow wild cards, like "java.lang.*", but have no idea how the wild cards can be implemented. I don't think there is an API in the classloaderr to get all the classes in a package.
>>
>> If wild cards are not allowed, do you think it is still useful to have imports?
>>
> I think people will still use it. The number of functions/enums in an app is often small, but often used in my experience (e.g. some String formatting).
>
>
>> I think it would still be useful to pre-import all java.lang classes, and that can be implemented by listing the classes in java.lang package, and do an explicit import of the classes in the list. Clunky, but works, and hidden from the user.
>>
> I think this alone makes this feature well worth having.
Good.
I've given more thoughts to importing packages. I think it can be
implemented by a somewhat brute force method. :-) Given a class name
without its package, we can trying loading it from the packages that
have been imported. So this would also be included.
Since classes that have been imported need to be available at parse
time, we'll need to add some functionalities in ELContext to handle
imports. I'll work out the details and present a proposal soon.
Kin-man