commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: import * vs explicit debate
Date Wed, 02 Apr 2003 21:42:14 GMT

Howdy,
I agree with Senor Ross.

The use of Jalopy (my fav) or another tool allows each developer to use
whatever mechanism they see fit for their own use.  But for releases, it
should definitely be explicit.

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Kevin Ross [mailto:Kevin.Ross@iVerticalLeap.com]
>Sent: Wednesday, April 02, 2003 4:39 PM
>To: 'Jakarta Commons Developers List'
>Subject: RE: import * vs explicit debate
>
>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:guru@stinky.com]
>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: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




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
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