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