Intent

[Kyle Lahnakoski]

Jason Marshall wrote:
> 
> 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.

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