[5827] in java-interest
Name clash in packages
daemon@ATHENA.MIT.EDU (garya@dreamchaser.org)
Wed Feb 28 17:54:36 1996
From: garya@dreamchaser.org
Date: Wed, 28 Feb 1996 15:02:21 -0700 (MST)
To: java-interest@java.sun.com
I am puzzled by the restrictions currently placed on the import and package
semantics.
The package mechanism allows one to have classes named the same in different
packages, but only if those packages are "mostly" unknown to each other.
For example:
PkgA PkgB
| |
C C
The class C can exist in both PkgA and PkgB only if PkgA/C,
or a user of PkgA/C,
does not import anything from PkgB which references PkgB/C.
The intent of the restriction, I assume, is to prevent subtle errors
where one subclasses or uses a class C, thinking it is from PkgA, and
instead gets the one from PkgB.
This is obviously a good thing to try to prevent.
However, it introduces another problem, namely, that it is now
impossible to write a package in a manner which deals with its
namespace in a safe way, without prepending a reserved string,
derived from the full package path name, to every class.
In the example above, if I am the provider of PkgA,
and PkgA is intended for distribution to a wide audience,
I must prepend something like PkgA_ to every class name.
Otherwise, some other vendor's package (PkgB) may be delivered
which also contains a class C, and if used in concert with
my package (PkgA), there will be a conflict.
Even more to the point, my own package may in the future have
a new class added to it, which would in itself conflict with
the classes some of the users of my package have created.
Yet the naming scheme used in the binary code, which prepends package
names to all class names, makes it possible to accurately distinguish
class references.
It is also possible for a compiler to distinguish class name references
using scoping rules, just as it does with variable references. The logical
scoping starts with the current compilation unit, extends to the package
of the current compilation unit, and then extends to other imported packages.
It is only in the case where two imported packages have the same class
that a potentially dangerous situation exists.
It seems to me that this situation, and only this situation,
should cause a compile time error.
This is because no matter what ordering of the imported packages is chosen,
adding a class with the same name to some other package being imported
could cause a change in the meaning of the package being compiled.
The language already allows fully qualified name constructs of the form:
PkgA.C foo;
foo = new PkgA.C();
so it *is* possible for a properly written program to already be totally
unambiguous, if the compiler would only let it.
Now, having said all that...
is this analysis correct?
And for the java language gods at Sun/Javasoft,
assuming all of the above is correct,
do you anticipate doing anything about it?
Or are those of us writing libraries going to have to deal with this
potential problem as we have with virtually every other language,
namely, prepending the equivalent of package names to all classes?
Gary Aitken garya@ics.com (business)
garya@dreamchaser.org (personal)
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
