You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jason van Zyl <ja...@zenplex.com> on 2002/10/01 22:30:10 UTC
Re: cvs commit:
jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/con
tainer/commands CheckTypeInfoCommand.java
DisposeComponentHandlerCommand.java InitializeComponentHandlerComm
On Tue, 2002-10-01 at 16:16, Giacomo Pati wrote:
> On Tue, 1 Oct 2002, Berin Loritsch wrote:
>
> > Giacomo Pati wrote:
> > > On Tue, 1 Oct 2002, Peter Royal wrote:
> > >
> > >
> > >>On Tuesday, October 1, 2002, at 02:55 PM, giacomo@apache.org wrote:
> > >>
> > >>
> > >>>giacomo 2002/10/01 11:55:59
> > >>>
> > >>> Modified:
> > >>>fortress/src/java/org/apache/excalibur/fortress/container/commands
> > >>> CheckTypeInfoCommand.java
> > >>> DisposeComponentHandlerCommand.java
> > >>> InitializeComponentHandlerCommand.java
> > >>> Log:
> > >>> get rid of global and unused imports (hope this is ok ;-)
> > >>
> > >>It is very ok :)
> > >
> > >
> > > Well, I've seen there are plenty of location with global imports in the
> > > fortress package. Is this intentional? Should I go for removing them?
> >
> > In many places we pretty much use the entire package. It is simpler/
> > shorter just to import the whole package. In most cases it is only done
> > with Framework classes.
>
> Siplicity is not allways the best way for people to study code. Excplicit
> imports clearly state which class belongs to which package.
+1
Glob imports are evil and make code really hard to navigate.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/con
tainer/commands CheckTypeInfoCommand.java DisposeComponentHandlerCommand.java
InitializeComponentHandlerCo
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>>
>>:/ Ok. Well, now that I have a really nice IDE that takes care of
>>import statements for me, its no real biggy anymore. When I had a
>>glorified text editor it was a real pain.
>
>
> What's the name of your nice IDE today?
IntelliJ IDEA (Early Access Program)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/con
tainer/commands CheckTypeInfoCommand.java DisposeComponentHandlerCommand.java
InitializeComponentHandlerCo
Posted by Giacomo Pati <gi...@apache.org>.
On Tue, 1 Oct 2002, Berin Loritsch wrote:
> Jason van Zyl wrote:
> > On Tue, 2002-10-01 at 16:16, Giacomo Pati wrote:
> >
> >>On Tue, 1 Oct 2002, Berin Loritsch wrote:
> >>
> >>>>
> >>>>Well, I've seen there are plenty of location with global imports in the
> >>>>fortress package. Is this intentional? Should I go for removing them?
> >>>
> >>>In many places we pretty much use the entire package. It is simpler/
> >>>shorter just to import the whole package. In most cases it is only done
> >>>with Framework classes.
> >>
> >>Siplicity is not allways the best way for people to study code. Excplicit
> >>imports clearly state which class belongs to which package.
> >
> >
> > +1
> >
> > Glob imports are evil and make code really hard to navigate.
>
> :/ Ok. Well, now that I have a really nice IDE that takes care of
> import statements for me, its no real biggy anymore. When I had a
> glorified text editor it was a real pain.
What's the name of your nice IDE today?
Giacomo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/con
tainer/commands CheckTypeInfoCommand.java DisposeComponentHandlerCommand.java
InitializeComponentHandlerComm
Posted by Berin Loritsch <bl...@apache.org>.
Jason van Zyl wrote:
> On Tue, 2002-10-01 at 16:16, Giacomo Pati wrote:
>
>>On Tue, 1 Oct 2002, Berin Loritsch wrote:
>>
>>>>
>>>>Well, I've seen there are plenty of location with global imports in the
>>>>fortress package. Is this intentional? Should I go for removing them?
>>>
>>>In many places we pretty much use the entire package. It is simpler/
>>>shorter just to import the whole package. In most cases it is only done
>>>with Framework classes.
>>
>>Siplicity is not allways the best way for people to study code. Excplicit
>>imports clearly state which class belongs to which package.
>
>
> +1
>
> Glob imports are evil and make code really hard to navigate.
:/ Ok. Well, now that I have a really nice IDE that takes care of
import statements for me, its no real biggy anymore. When I had a
glorified text editor it was a real pain.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-excalibur/fortress/src/java/org/apache/excalibur/fortress/con tainer/commands CheckTypeInfoCommand.java DisposeComponentHandlerCommand.java InitializeComponentHandlerComm
Posted by Peter Donald <pe...@apache.org>.
On Wed, 2 Oct 2002 06:30, Jason van Zyl wrote:
> > Siplicity is not allways the best way for people to study code. Excplicit
> > imports clearly state which class belongs to which package.
>
> +1
>
> Glob imports are evil and make code really hard to navigate.
+1
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>