> On Wed, 26 Aug 1998 11:33:42 -0300 (ADT), Kenny Freeman wrote:
>
> >
> >> I personally am rather against most import statements as they can
> >> only help to confuse the issue of what you are looking at. Even worse
> >> is import of a whole package - since then you do not even see in the
> >> code all of the possible class names that just got defined... However,
> >> if used very rarely and only when really justified, they can help
> >> reduce the typing needed and not reduce the maintainability of the code.
> >>
> >> Sorry about that, but I have had to fix code where the top of the
> >> file had import xxxx.*; import yyyy.*; etc. Basically importing every
> >> package in the whole product - almost 30 lines of these - and then
> >> trying to figure out what the DataTrack class is and which one it used -
> >> since there was a different one in three different packages...
> >>
> >> BTW - This was only one person who did this in his souce - and his
> >> code was usually the code we had to fix. But he was a contractor and
> >> did not follow our coding standards.
> >
> >Well, that is still no real argument against packages. However the
> >xxxx.whatever packages were generated, there should have been a way to
> >make things a bit less cryptic. I couldn't imagine not being able to use
> >the import statement. Things like:
> > tmp = new ken.encryption.RSA.RSAMessageDigest(....)
> > tmp2 = new ken.util.file.FileReader("blah.txt")
> >get on my nerves pretty quick. People who make bad names for packages like
> >xxxx should keep there code to themselves. Well, thats my $ 0.02
>
> No, it names were not xxxxx. I just am not in a position to explain the
> names. The names were nice, but the imports where all of the type:
>
> import ORG.junk.foo.bar.*;
> import ORG.junk.blah.foo.*;
> import ORG.junk.blah.bar.*;
>
> etc. for about 30 lines...
>
> So, the code was importing classes that it never needed or used,
> it was importing conflicting classes, and it was very hard to maintain.
> (All of his source files started with the same set of lines but none
> of them used all of the classes...)
>
> I would have liked it if the import statement could *not* have "*"
> and thus you would have to:
>
> import ORG.junk.foo.bar.TimeTrack;
> etc.
>
> This way you would always have a true listing of what you have imported
> and from where. (The "*" just is a problem.)
>
> Personally, I never use that. I have an editor that makes life easier
> and I can type rather quickly, so I have fully qualified names on all
> classes that are outside of the package that the source is in. It also
> means that when I read the code I can see instantly what package the class
> came from.)
>
> Michael Sinz -- Director of Research & Development, NextBus Inc.
> mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
> My place on the web ---> http://www.users.fast.net/~michael_sinz
>
>
I see your point now. I agree with you when you say doing this is a bad
thing:
import foo.bar.*;
import foo2.bar2.*;
This does cause problems and is not nec. a good thing to do - but I was
generally thinking allong the lines of importing one or two utility
classes to save me the trouble of typing out the really long names.
Importing * is a bit lazy, and in larger classes really does make it
difficult to keep things organized. Like you said, if you don't import *,
but list every class like:
import ken.encryption.RSA.RSAMessageDigest;
import ken.util.FileReader;
it makes it more obvious what classes are used compared to the *, where
you really have to go through the code and find out.
