You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alex Chaffee / Purple Technology <gu...@stinky.com> on 2003/04/02 23:32:56 UTC
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
Re: import * vs explicit debate
Posted by Costin Manolache <cm...@yahoo.com>.
My 2c:
- if you use an editor that supports explicit imports - it doesn't matter
if it's one way or the other.
- if you use an editor that supports simple navigation ( click some keys
and you go to the class definition ) - again it doesn't matter.
- if you use vi/emacs or another fast editor ( which doesn't support
explicit imports ) - implicit imports is a _huge_ pain, and very little
could justify it. Even if you take the pain, it's very likely you'll
soon end with many unused imports ( and more pain if you want to clean them
). Pain is not good, it kills the fun of programming.
So my opinion is that everyone should write in whatever style he is
comfortable with. If you happen to use an editor that can reorganize
the imports and you edit a file that has * imports ( or has unused imports
)- then it is a good idea to hit the magic keystroke and convert.
It would be a bad idea IMO to require people using vi/emacs/etc to manually
do what can be easily automated.
( after using xdoclet for a while - you'll get the same feeling about
writing standard mbeans, EJB or taglibs ).
Costin
>> 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
Re: import * vs explicit debate
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 2 Apr 2003, __matthewHawthorne wrote:
> I apologize if anyone has already made this point, but...
>
> If I'm writing code that uses a class called org.cavity.Thing...
>
> import org.cavity.*
> import org.apache.*
>
> public class Test {
>
> Thing t = new Thing();
>
> }
>
> But later on, if the class org.apache.Thing is created, the code will no
> longer compile, right?
>
> Isn't this an untouchable reason for using explicit imports?
Yes it is. Ever since I found this out the hard way, I've avoided * like
the plague. I'd wager that anyone who feels otherwise would rapidly change
their mind the first time they add a class to their library and have their
user base whining because that new class broke their client builds. ;-)
--
Martin Cooper
>
>
>
> On Wed, 2003-04-02 at 16:54, Alex Chaffee / Purple Technology wrote:
> > On Wed, Apr 02, 2003 at 04:45:17PM -0500, Henri Yandell wrote:
> > >
> > > 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.
> >
> > Hmmm. Clever.
> >
> > On the other side, I could get my desired auto-complete behavior by an
> > option "Auto-Complete Uses Full Package Of External Imports" (or
> > something less incomprehensible).
> >
> > Against Being Anti -
> >
> > - A
> >
> > --
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: import * vs explicit debate
Posted by Juozas Baliuka <ba...@centras.lt>.
Yes,
"will no longer compile" is advantage for me too.
I found ".*" ans "short" package names are better to use in practice, but I
do not believe it is possible to find "the best way".
----- Original Message -----
From: "Alex Chaffee / Purple Technology" <gu...@stinky.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, April 03, 2003 2:45 AM
Subject: Re: import * vs explicit debate
> On Wed, Apr 02, 2003 at 06:52:26PM -0500, __matthewHawthorne wrote:
> >
> > But later on, if the class org.apache.Thing is created, the code will no
> > longer compile, right?
>
> Right.
>
> > Isn't this an untouchable reason for using explicit imports?
>
> No; it's a reason for doing a full clean build and unit test run
> before checking in any changes.
>
> This way whoever added org.apache.Thing, or updated the library that
> added it, is responsible for not breaking everyone else's build.
>
> In this case causing a compiler error is good; the error will mention
> the name of the class that was just added; and the adder will say "oh,
> duh" and know what to do to fix it. More troublesome are interface
> changes that are silently absorbed but cause semantic changes.
>
> --
> 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
Re: import * vs explicit debate
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Apr 2003, Alex Chaffee / Purple Technology wrote:
> Date: Thu, 3 Apr 2003 09:49:26 -0800
> From: Alex Chaffee / Purple Technology <gu...@stinky.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> alex@jguru.com
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Cc: alex@jguru.com
> Subject: Re: import * vs explicit debate
>
> Craig -
>
> I'm not trying to be argumentative here, but I'd like to understand
> your position (and clarify mine).
>
> The situation I was describing was as follows:
>
> Project A uses Library X.jar (v1.0). Alphonse is a developer on
> Project A.
>
> Xavier is a developer on Project X. He updates Project X and
> publishes a new version of Library X.jar (v1.1).
>
> Alphonse imports the new version of X.jar into Project A.
>
> Now, I think we'd agree that Alphonse should do a full build of
> Project A before he checks in the new version of X.jar, right?
>
Absolutely. Promises of binary-level backwards compatibility are very
hard to achieve, because they can be broken by changes in the inheritance
hierarchy of a class in A (say, you factor an implemented interface into
two different ones), even though the set of public methods visible to
users has not changed.
> That's the stage I was talking about. Since Alphonse had to
> explicitly import the new version of X.jar, he has a pretty good idea
> that any compile errors that say "ambiguous class involving
> org.X.SomeClass" are due to interface changes introduced in the X.jar
> he just imported.
>
Yes, he will understand this error message, but why should he have to? If
Alphonse always used explicit imports, this kind of error message would
never show up at all, and his build would have never been broken.
> Your argment seems to be that Xavier should not be responsible for
> recompiling and fixing Project A (and all other clients of Library X).
> I totally agree with you there.
I was actually arguing that Xavier should not need to go ask Alphonse for
permission to add a new class to X -- which is what I thought you were
suggesting. If I misread your train of thought on this, I'm sorry.
>
> But the Maven/Gump procedure is messing with that scenario a bit. Are
> you saying that it promotes *automatic* updates of all clients when a
> library is updated? In that world, Alphonse does not exist; he is
> replaced by a script (or just an automatic Ant-based web download).
>
Nearly all of the Maven project files I have seen ask for specific
versions of their dependencies. You can override this locally if you want
to say "no matter what the project file says, *I* want to use this
particular version of a dependent JAR"), but I would bet most people don't
actually do it.
If Alphonse is using Maven, he'd simply update the version number for
Project X in the project descriptor file, and rerun the build. You might
indeed get "ambiguous class" warnings, but why should you have to?
Dealing with them is a waste of time when they could have been avoided in
the first place.
> This scenario is a little troubling, since it introduces the
> possibility of semantic changes as well as syntactic ones.
Dealing with "ambiguous class" error messages is simply annoying. Dealing
with semantic changes where Alphonse introduces a new class in A that
happens to shadow a class of the same name in X, and happens to have
public methods with compatible signatures, is dangerous -- Alphonse has
now got a totally mysterious semantic change in A, without any compiler
errors to warn him about it.
> This
> transcends the import issue. If this is so, is there a rationale for
> it somewhere I can read up on?
>
A rationale for what? If it's for explicitly defining dependencies in a
Maven project file, the whole point is to automate the entire build
process. For an example of how painful it can be without this, go grab
the source code for Tomcat 4.0, and assemble the right versions of the 25
or so external dependencies manually :-).
> Note that I actually think this procedure is great, and can accelerate
> development, as long as everyone involved understands the risks.
>
If "this procedure" means use "*" imports, I disallow it on my for-pay
projects where I have architectural responsibilities, for the reasons
outlined above. For my Apache work, you'll never see a wild card import
in any of the code I write, because it's much easier to avoid ambiguous
classes in the first place than to deal with them later. And for the
projects where the other committers listen to me (Struts, the commons
packages that I'm directly working on), you'll see consistent use of
explicit imports as well.
I'm pretty good at creating bugs all by myself -- it just makes sense to
avoid practices that are likely to create more of them simply by an
unfortunate choice of a new class name :-).
> Cheers -
>
> - A
Craig
>
>
> > > No; it's a reason for doing a full clean build and unit test run
> > > before checking in any changes.
> > >
> >
> > That only works for code in your own packages -- not in packages you
> > depend on from other people (especially those that you use binaries for,
> > as things like Maven encourage you to do even if the underlying package is
> > open source).
> >
> > > This way whoever added org.apache.Thing, or updated the library that
> > > added it, is responsible for not breaking everyone else's build.
> > >
> >
> > In other words, I (as the author of one or more commons components) is
> > supposed to ask ***every*** user of that component "will adding a new
> > class Foo in my package cause your build to break?" Yah, right.
> >
> > It's not my problem. It's the problem of the person who used "*" imports.
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> --
> 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
Re: import * vs explicit debate
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 3 Apr 2003, Alex Chaffee / Purple Technology wrote:
> But the Maven/Gump procedure is messing with that scenario a bit. Are
> you saying that it promotes *automatic* updates of all clients when a
> library is updated? In that world, Alphonse does not exist; he is
> replaced by a script (or just an automatic Ant-based web download).
Yep. One aspect of Maven [it's optional] is that all our projects build at
midnight, a SNAPSHOT version is created and anyone who builds a project
the next day is likely to get that new version [assuming they're working
on something which has declared itself to use the SNAPSHOT].
I think it's probably better to be doing lots and lots of micro-versions,
but that seems to cost a lot in terms of upgrading the version each module
depends upon. The SNAPSHOT methodology is easier to work with and makes it
break earlier rather than later.
I imagine there's probably some big academic philosophical argument out
there somewhere about whether breaking earlier is better or worse than
breaking later.
> This scenario is a little troubling, since it introduces the
> possibility of semantic changes as well as syntactic ones. This
> transcends the import issue. If this is so, is there a rationale for
> it somewhere I can read up on?
>
> Note that I actually think this procedure is great, and can accelerate
> development, as long as everyone involved understands the risks.
Yeah, pretty much my view. Day to day is great, but every now and then the
development-train crashes and we have to unravel pecularities.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: import * vs explicit debate
Posted by Alex Chaffee / Purple Technology <gu...@stinky.com>.
Craig -
I'm not trying to be argumentative here, but I'd like to understand
your position (and clarify mine).
The situation I was describing was as follows:
Project A uses Library X.jar (v1.0). Alphonse is a developer on
Project A.
Xavier is a developer on Project X. He updates Project X and
publishes a new version of Library X.jar (v1.1).
Alphonse imports the new version of X.jar into Project A.
Now, I think we'd agree that Alphonse should do a full build of
Project A before he checks in the new version of X.jar, right?
That's the stage I was talking about. Since Alphonse had to
explicitly import the new version of X.jar, he has a pretty good idea
that any compile errors that say "ambiguous class involving
org.X.SomeClass" are due to interface changes introduced in the X.jar
he just imported.
Your argment seems to be that Xavier should not be responsible for
recompiling and fixing Project A (and all other clients of Library X).
I totally agree with you there.
But the Maven/Gump procedure is messing with that scenario a bit. Are
you saying that it promotes *automatic* updates of all clients when a
library is updated? In that world, Alphonse does not exist; he is
replaced by a script (or just an automatic Ant-based web download).
This scenario is a little troubling, since it introduces the
possibility of semantic changes as well as syntactic ones. This
transcends the import issue. If this is so, is there a rationale for
it somewhere I can read up on?
Note that I actually think this procedure is great, and can accelerate
development, as long as everyone involved understands the risks.
Cheers -
- A
> > No; it's a reason for doing a full clean build and unit test run
> > before checking in any changes.
> >
>
> That only works for code in your own packages -- not in packages you
> depend on from other people (especially those that you use binaries for,
> as things like Maven encourage you to do even if the underlying package is
> open source).
>
> > This way whoever added org.apache.Thing, or updated the library that
> > added it, is responsible for not breaking everyone else's build.
> >
>
> In other words, I (as the author of one or more commons components) is
> supposed to ask ***every*** user of that component "will adding a new
> class Foo in my package cause your build to break?" Yah, right.
>
> It's not my problem. It's the problem of the person who used "*" imports.
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
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
Re: import * vs explicit debate
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 2 Apr 2003, Alex Chaffee / Purple Technology wrote:
> Date: Wed, 2 Apr 2003 16:45:27 -0800
> From: Alex Chaffee / Purple Technology <gu...@stinky.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> alex@jguru.com
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: import * vs explicit debate
>
> On Wed, Apr 02, 2003 at 06:52:26PM -0500, __matthewHawthorne wrote:
> >
> > But later on, if the class org.apache.Thing is created, the code will no
> > longer compile, right?
>
> Right.
>
> > Isn't this an untouchable reason for using explicit imports?
>
> No; it's a reason for doing a full clean build and unit test run
> before checking in any changes.
>
That only works for code in your own packages -- not in packages you
depend on from other people (especially those that you use binaries for,
as things like Maven encourage you to do even if the underlying package is
open source).
> This way whoever added org.apache.Thing, or updated the library that
> added it, is responsible for not breaking everyone else's build.
>
In other words, I (as the author of one or more commons components) is
supposed to ask ***every*** user of that component "will adding a new
class Foo in my package cause your build to break?" Yah, right.
It's not my problem. It's the problem of the person who used "*" imports.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: import * vs explicit debate
Posted by Gavin McPhee <ga...@objectconnections.com>.
> No; it's a reason for doing a full clean build and unit test run
> before checking in any changes.
> This way whoever added org.apache.Thing, or updated the library that
> added it, is responsible for not breaking everyone else's build.
> In this case causing a compiler error is good; the error will mention
> the name of the class that was just added; and the adder will say "oh,
> duh" and know what to do to fix it. More troublesome are interface
> changes that are silently absorbed but cause semantic changes.
I totally agree.
Gavin McPhee
Senior Software Engineer
Object Connections Australia
www.objectconnections.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: import * vs explicit debate
Posted by Alex Chaffee / Purple Technology <gu...@stinky.com>.
On Wed, Apr 02, 2003 at 06:52:26PM -0500, __matthewHawthorne wrote:
>
> But later on, if the class org.apache.Thing is created, the code will no
> longer compile, right?
Right.
> Isn't this an untouchable reason for using explicit imports?
No; it's a reason for doing a full clean build and unit test run
before checking in any changes.
This way whoever added org.apache.Thing, or updated the library that
added it, is responsible for not breaking everyone else's build.
In this case causing a compiler error is good; the error will mention
the name of the class that was just added; and the adder will say "oh,
duh" and know what to do to fix it. More troublesome are interface
changes that are silently absorbed but cause semantic changes.
--
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
Re: import * vs explicit debate
Posted by __matthewHawthorne <mh...@stargate.net>.
I apologize if anyone has already made this point, but...
If I'm writing code that uses a class called org.cavity.Thing...
import org.cavity.*
import org.apache.*
public class Test {
Thing t = new Thing();
}
But later on, if the class org.apache.Thing is created, the code will no
longer compile, right?
Isn't this an untouchable reason for using explicit imports?
On Wed, 2003-04-02 at 16:54, Alex Chaffee / Purple Technology wrote:
> On Wed, Apr 02, 2003 at 04:45:17PM -0500, Henri Yandell wrote:
> >
> > 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.
>
> Hmmm. Clever.
>
> On the other side, I could get my desired auto-complete behavior by an
> option "Auto-Complete Uses Full Package Of External Imports" (or
> something less incomprehensible).
>
> Against Being Anti -
>
> - A
>
> --
> 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
Re: import * vs explicit debate
Posted by Alex Chaffee / Purple Technology <gu...@stinky.com>.
On Wed, Apr 02, 2003 at 04:45:17PM -0500, Henri Yandell wrote:
>
> 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.
Hmmm. Clever.
On the other side, I could get my desired auto-complete behavior by an
option "Auto-Complete Uses Full Package Of External Imports" (or
something less incomprehensible).
Against Being Anti -
- A
--
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
Re: import * vs explicit debate
Posted by Henri Yandell <ba...@generationjava.com>.
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
RE: import * vs explicit debate
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
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