Sat, 08 Apr 2000 16:47:45 -0400
Jason Marshall wrote:
> Kyle wrote:
> >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.
I am assuming you are saying that an advantage of namespaces is that
many names can map to a single UID. If that is so, my proposed method
already can handle that.
> 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.
MMMmmmm. I do not understand "Since internal representations between
two functionally equivalent modules will definitely not be 100%
identical, ..." May you expand on this?
> 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.
True, that can be an issue. It is up to the compiler/IDE to
resolve the context of the identical names presented to the user. Right
now I solve ambiguity, ungracefully, with #<ID> appended to the name of
the objects experiencing naming conflicts. E.G. foo#386445. This
rarely happens with parameters because the message context is sufficient
to determine the parameter name uniquely.
Kyle Lahnakoski Arcavia Software Ltd.
(416) 892-7784 http://www.arcavia.com