My 2 cents ;) 1. Implicit is best while in major development (for code completion). 2. Explicit is best (by far) when code is stable. 3. Imports should be optimized (explicit) for any major or minor release.
Anything spelled out (explicit) is much easier to comprehend than something that is not (implicit). This is a major advantage for a community of developers since code comprehension is accelerated. -Kevin Ross -----Original Message----- From: Alex Chaffee / Purple Technology [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2003 3:33 PM To: Jakarta Commons Developers List Subject: import * vs explicit debate OK, fine, it looks like the debate is raging already, so I'll chime in: On Wed, Apr 02, 2003 at 03:19:45PM -0500, Henri Yandell wrote: > > Biggest pain for me was discovering a large codebase with a lot of > unfamiliar package names that were all .* imported. Made it quite hard to > have a clue what things were. So it's an educational thing? If unfamiliar source code uses a class Foo, then you must (a) discover what package Foo is in, and (b) read the docs for it. You're saying that explicit imports help with (a), but they can't help with (b), right? Modern IDEs, help browsers, and the JavaDoc all-classes index all allow you to accomplish (a) very easily. For instance, auto-complete or tag-aware IDEs (including Emacs) let you click or keystroke on a symbol and jump right to the definition for it. But the main counter-argument is, this is only useful in the very beginning of your use of an unfamiliar source file -- or rather, of a source file that uses an unfamiliar package. As soon as you have a basic comprehension of the package, the disadvantages of having a huge list of explicit imports outweigh that one advantage. I'd rather optimize for the 95% case than the (admittedly occasionally confusing) 5% case. > There is the clash example as well of course. java.util.Data/java.sql.Date > and others. That's a problem that's been solved since Java 1.0. import java.util.*; import java.sql.*; import java.util.Date; It's actually clearer this way, since the final line is explicitly saying "Date is a clash -- watch out" rather than burying the potential clash in a big-ass list. > The usual argument against being anti .* is that IDE's can be used to > figure out where a package lies, "against being anti?" :-) My two favorite IDEs, IDEA and Eclipse, have both Optimize Imports and Auto-Complete. With * imports, that means that once I use one class in a package, I get auto-complete for all classes in that package. This makes my development much smoother. I get to type Map map then IDEA's lightbulb asks me if I want to import, so Alt-Enter-Enter adds import java.util.* up at the top of the file, then I type = new Ha then Ctl-space autocompletes "shMap" since it's already imported an in the symbol table. But with explicit imports, I couldn't get that auto-complete -- I'd have to type out "HashMap" and then Alt-Enter-Enter import it too. Even more compelling is using auto-complete as a package documentation browser. If I don't remember the full name of a class, I can type what I think the first few letters are, and I see all names that match in all imported packages. Again, with explicit imports, I don't have that information. > but that argument is quite poor as the > IDE can also be creating nice import statements. And which set of import statements is more "nice" -- import java.util.Map; import java.util.HashMap; import java.util.TreeMap; import java.util.ArrayList; import java.util.List; import java.util.ArrayList; import java.blah.Blah; import ad.Nauseam; or import java.util.*; import java.blah.*; import ad.*; To my eye, the latter is more nice. > The other argument is that the imports use up lots of space. IDEs can wrap > up the imports into one line. More of a pain for text-editor users. But whether they're collapsable or not, when expanded, the big lists are much harder to grok. Essentially they serve as targets for a find command -- and I prefer an explicit "find symbol by name" function which is more reliable anyway. > > - Inability to tell specific dependencies just by glancing at the source > > code And this is important why? And how often is it useful? > > - Increased difficulty when refactoring, either manually (with grep / > > perl) or by IDEs that support refactoring and nearly always require > > import cleanup as a preliminary step. Huh? I've been refactoring, manually and with tools, for a couple years and I find it *easier* to do with .* imports. Using manual imports, it means that if I move a method that uses class C from class A to class B, there's a good chance that C is already imported (via *) inside B, so I don't have to change the imports at all. And once I do add C's package to the imports list, the next refactorings have it available. Automated tools, as you mention, do the right thing no matter what. I use Optimize Imports primarily to remove unused packages from the import list. > > >>Import .* is annoying I disagree :-) > > > and all the jakarta projects should have import > > >>cleanups as part of their build.xml IMHO. I agree -- but with them cleaned to all use *. -- Alex Chaffee mailto:[EMAIL PROTECTED] Purple Technology - Code and Consulting http://www.purpletech.com/ jGuru - Java News and FAQs http://www.jguru.com/alex/ Gamelan - the Original Java site http://www.gamelan.com/ Stinky - Art and Angst http://www.stinky.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
