On Mon, 3 May 1999, Michael Sinz wrote:
>class layout of java. So yes, it's fine that you declared a
>variable as:
>
>java.util.List foo;
Actually, I feel that the real problem is that import lets you
use a wildcard. That is, IMHO, the real design flaw in Java.
If import required fully qualified names at all times things
would be much better. As it is now, many people import the world
which makes the packages basically useless (everything is mushed
together into a single name space) The nice thing about packages
is that you can have the same class name (due to whatever reasons)
in multiple packages and not have to give each one a strange name.
(Why have to make Jfoo, Nfoo, etc., when it really is a foo?)
That an import uses a wildcard can also be a strength. One of the
merits of Java lies in its maintainability. Without the ability to
import entire package, packages whose structures are being changed
(generated code is notorious for having this problem) would have large
maintainance issues when names changed. Also, when you decide to use
another class in your application, you'll have to add the
corresponding import. Sounds like an unnecessary time-sink. It still
doesn't solve the List problem...
Importing each class is somewhat unnecessary, since importing both
java.awt.List and java.util.List doesn't resolve the dependency.
You'd still have to unambiguate between List classes.
To extend your own words, why call it a javax.swing.JPanel
when you can just call it a JPanel?
I agree that one, large namespace is impractical (see C++ =), but
there are times when it's simply more convenient. Design flaws which
deviate from beautiful (IMHO, though it's a little late)can exist--and
should exist, sometimes--for purely pragmatic reasons.
--troy
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
