Proposal: Import Aliases for Classes and Static Methods (original) (raw)

Phil Varner philvarner at gmail.com
Thu Mar 5 20:50:26 PST 2009

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.

More information about the coin-dev mailing list