> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Jim LoVerde
> Sent: Monday, October 30, 2000 2:25 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: A command to kill extra import statements
>
>
> > As a style issue, listing each class is more of a maintenance
> > nightmare than any benefit (class collisions are very rare; import
> > statements are not a reliable source of class
> dependencies). The new
> > JDE features to clean up the import list goes a long way to
> help this,
> > though. Thanks for creating it!
>
> Regarding style and maintenance, I vehemently disagree for
> this reason:
> maintenance is defined as changing code, correct? Well
> consider this scenario:
>
> 1. You write a class called FooWidget that imports java.awt.*
> 2. You complete your testing of this class and it is good.
> 3. A new JDK comes out with a java.awt.FooWidget class.
>
> So without changing a single line of your code, you will
> discover that when
> trying to compile with the new JDK your class has been
> broken. Had you used
> explicit imports this would not have happened.
Actually, it is the other way around. The easy explanation that mimics
yours is in "The Java Language Specification", page 126 of the 2nd edition:
"If another top level type with the same simple name is otherwise declared
in the current compilation unit except by a type-import-on-demand
declaration then a compile-time error occurs. So the sample program:
import java.util.Vector;
class Vector {Object[] vec;}
causes a compile-time error because of the duplicate declaration of
Vector..."
This:
import java.util.*;
class Vector {Object[] vec;}
compiles because of package scoping, and your example above will not.
This is an argument for on-demand import declarations, not against.
> While class collisions are usually rare, they are often a
> source of extreme
> confusion. Also, from a documentation standpoint when you
> see a "List" class it
> is much easier to resolve this class if the developer used
> explicit imports
> rather than a bunch of .* imports leaving you to search for
> any matching class
> name.
Yes, I also like that. import declarations easily get out of date with
class evolution, so they are not truly/always reliable as a dependency
source. But, I also look there first to see "which one is it using
here...". With David's new feature in JDE, Emacs JDE users will very easily
keep it up to date! This is a good thing. :-)
> But alas, this is yet another religious issue that seems to
> create almost as much
> furor among developers as the simple rule that you should
> never use tabs in your
> source code ;^)
Indeed! I actually am not emotional about this issue, and see strengths of
each way. I liked your and others info to learn more about it. Recently I
have been thinking on-demand is better since I cannot come up with an
overwhelming argument (other than a group's coding standards edict it one
way or another) to keep doing it single-type, and I find maintenance easier
with on-demand. It started when I read about this in "Java 2 Performance
and Idiom Guide" (a great book!). We also have been mainly doing
single-type, and I have been trying to find others opinions and practices.
Thanks for yours!
> ****************************************************
> Jim LoVerde, Technical Architect
> nVISIA (formerly STR)
> http://www.nvisia.com
> voice: 312.674.4798 fax: 312.697.3801
> mobile: 773.398.9539 pager: [EMAIL PROTECTED]
>
>
