Sat, 08 Apr 2000 13:10:57 PDT
>This brings up a question of mine concerning namespaces. There is
>a lot of talk of namespaces. I am of the belief that namespaces
>to the personal compiler/IDE of the programmer, not the system. The
>system just manages unambiguous ID values, the compiler converts
>intended human meaning (source code) into pure ID communication. For
>that reason the semantics/syntax of the code used to communicate with
>Tunes-like system is irrelevant. I created "ObjectCode" knowing that
>will have a short life span. ObjectCode only has the minimal
>expressiveness required for a reflective system.
>Can someone tell me what others are seeing when they speak of
>namespaces. What issues are namespaces solving that the above mapping
>idea does not?
Java uses a namespace system that helps avoid unintended naming
collisions, based upon the domain name of the originator. I suppose
one could use the domain IP address in a pure numeric system, but I
don't believe this is necessary. Because you can work with namespace
identities at link-time, replacing many unique strings with a single
instance, you can get something (e.g. reference to a signature), that
is functionally equivalent to your UID, but one that is unique within
the execution/compilation environment.
Where namespaces fail is when another provider wants to create a drop-
in replacement for an existing package, or like the case of the Swing
package, some yutz couldn't come up with one namespace and keep it, and
hence there's a bunch of code out there that fails to link to the
intended module. A simple fix for this would be to provide a mechanism
for namespace aliasing, where the user can modify (or run code that
modifies) their local namespace aliases.
One problem with aliasing comes when you wish to persist data. Since
internal representations between two functionally equivalent modules
will definitely not be 100% identical, you need to be able to store the
actual name of the object, as opposed to the logical name, but I don't
see this as an intractable problem.
Another area that may suffer would be RTTI, because there are various
situations in which one may end up with both modules loaded, via a load
of persisted data.
I'm not sure if this can be sorted out with loading indirection through
a module loader (or class loader) that keeps them from bumping so
forcefully into each other. Diligent separation of type from
implementation may play a role in sorting out such interactions as
well. I hadn't thought of this issue until just now, so it will take
some consideration before I can give any sort of enlightened answer on