At 4:54 AM -0700 5/3/99, Troy Wu wrote:
>I agree that one, large namespace is impractical (see C++ =), but
>there are times when it's simply more convenient.
Especially since C++ allows you to overload = and it is smart enough
to not die at compile time. It just checks what types you have on each
side and runs the = from that class. If java weren't so paranoid, it would
trust
that the programmer is not only aware that they have a conflicting class
name in the same namespace, but that they've used it properly. For example,
java.util.List is an interface, so why isn't javac (or jikes) smart enough
to realize that when I type:
List foo = new ArrayList();
that I'm obviously not talking about java.awt.List, since ArrayList doesn't
inherit from it?! Clearly, this gets much more complicated, as you can have
constructors which may take the same arguments. Then you could perhaps
look at the other methods which are called on object foo to see which class
they are found in. If you give me 10 seconds with an "ambiguous method",
I can tell you what the programmer meant, even without reading comments,
and I wish that javac would at least try. If it can't figure enough out to be
sure, then I probably messed something up and I'm happy to see a
compile-time error.
But I do think overloading class names is an important part of a robust
language.
In addition, I think importing * is great for maintenance and flexibility.
But I
still maintain that Sun didn't realize the conflict in java.awt.List and
java.util.List
before they shipped 1.2 out the door (or almost shipped it anyway). If
they did
realize, then the problem arises mostly from a lazy implementation of
javac, IMHO.
Hmm...this discussion clearly doesn't belong on this mailing list.
Sorry about that. I thought my initial response would be the end
of it.
-Will
___________________________________________
Will Koffel Course 21M
(617) 225-6428 ~*_*~
[EMAIL PROTECTED] Course 6
MIT '00 http://web.mit.edu/wkoffel/www
-------------------------------------------
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
