On 08/08/11 09:31, Kin-man Chung wrote:
> 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.
>
Correction: imports are used at evaluation time, not parse time. At
parse time, T(name) is recognized as a class name. It's full name is
only needed at evaluation.
> Kin-man