commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: import * vs explicit debate
Date Wed, 02 Apr 2003 21:45:17 GMT


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:alex@jguru.com
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message