Proposal: Import Aliases for Classes and Static Methods

[Reinier Zwitserloot]

package imports would solve all these problems no, and be simpler to  
boot?

My major concern with type aliases is code snippets: When people post  
a snippet, they almost never include import statements. Many IDEs ship  
out-of-the-box as collapsing import statements but nothing else. They  
aren't generally considered important to grok any code snippet. But  
with type aliases, that changes. Note that anybody casually perusing a  
complete source file is effectively still 'reading a snippet', so to  
speak, though at least an IDE can help and e.g. jump to the proper  
class when ctrl+clicking the type, or showing the complete type in a  
tooltip.

You don't have that problem with package imports. "sql.List" is about  
as easy to type as "SQLList", and it does not create the inherent  
confusion in the name that "SQLList" has; I would interpret any type  
named "SQLList" as "A List contain SQLs, whatever those are".

Someone else will need to adapt or rewrite a proposal (my plate is  
full). Package imports don't help if the only difference in the FQN is  
near the front, but I don't know of any two commonly used classes  
together that differ only near the front. (e.g. sunw.io.Serializable  
vs. java.io.Serializable can't be simplified with package imports,  
but, nobody uses sunw.*, so not a relevant use case).

  --Reinier Zwitserloot



On Mar 6, 2009, at 05:50, Phil Varner wrote:

>> Static import was surprising complicated in JDK 5.  While these  
>> aliases could alleviate some problems, I think they would be easily  
>> abused
>> and even when not being abused render code less readable.
>> IMO, having alternate names for potentially common classes would be  
>> less readable.
>
> I agree for common classes this could be a problem, but I don't think
> it would be any less of a problem than the existing support for
> wildcards.  I see this more as a solution targeted mostly for long
> package names with overlapping class names.  I'm going to need to
> think some about what "readable" really means, and would be interested
> in any thoughts on this topic.
>
>> While grammar changes are part of the picture, the substantive  
>> changes would be to JLSv3 section 6.5 "Determining the Meaning of a  
>> Name":
>
> Thanks for pointing this out, it's definitely a huge hole in the  
> proposal.
>
>> The Javapolis discussions of 2007 ended with the majority of
>> participants choosing against aliasing of imports (typedefs).
>>
>> http://www.javapolis.com/confluence/plugins/advanced/gallery-slideshow.action?pageId=32793&decorator=popup&imageNumber=9
>
> Thanks for the pointer.  I, too, would probably vote against a the  
> proposal of
> import Map<String,Integer> as CodeValueMap;
>
> Several of the related bugs mention this syntax, but I think this
> combines two issues together.  It seems to me that the simple mapping
> of a fully-qualified class name to a "short" name is separate from the
> typedefing of a specifically-parameterized generified type to a short
> name.
>
> --Phil
>
> -- 
>
> Machines might be interesting, but people are fascinating. -- K.P.
>