Intent

[Jason Marshall]

Kyle wrote:
>This brings up a question of mine concerning namespaces.  There is 
quite
>a lot of talk of namespaces.  I am of the belief that namespaces 
belong
>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 
a
>Tunes-like system is irrelevant.  I created "ObjectCode" knowing that 
it
>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 
the subject.

-Jason