Hello,
You said you have an editor "that makes life easier". What's that for?
Thanks for your answer.
-jec
> -----Original Message-----
> From: Michael Sinz [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 26, 1998 4:50 PM
> To: Kenny Freeman
> Cc: [EMAIL PROTECTED]
> Subject: re: packages
>
> 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
>
