Wow. I was impressed at all the things I'd said, before I realised the second half weren't mine. Damn.
It's always fun when this debate comes up :) I think one of the biggest problems is the IDE. They do not separate the model and the view. For example, I should be able to say: Show me the source in this style, but do not modify the underlying style. Any change I make should adhere to that style. Tricky to implement probably, but that's my user-demand. Then I could do a concious restyle decision to change the actual model. Hen On Wed, 2 Apr 2003, Alex Chaffee / Purple Technology wrote: > 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]
