Namespace issues (was: Re: Intent)

[Jason Marshall]

>> 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.

I was saying that, but not as the main point I was trying to make.  
ID's will be a bit harder to make globally unique.  These sorts of 
schemes seem to work with hardware, but for some reason don't work as 
well with software.  Developers chafe at the notion.  For the point you 
latched onto, regarding UIDs, a runtime could, at its discretion, 
fairly simply turn harder-to-parse-but-human-friendly names into 
something that's equivalent to your numeric ID.  They wouldn't need to 
be globally unique IDs, just locally unique IDs, with a trivial lookup 
mechanism.  This sort of construct has been implemented quite a few 
times, and in a number of ways, so this wouldn't be rocket science.

In other words, I was saying that machine friendly names won't gain you 
a whole lot, in the long run, and may hurt you, if developers get 
annoyed with them.

>> 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?

Sure thing.  Let's say you have a standard library that contains common 
collection algoritms.  Let's say the standard implementation is 
appreciably bloated enough to tempt someone to reimplement it.  So my 
implementation gets rid of a bunch of extraneous state-keeping data 
within these containers.  If I dump instances of both to disk, I'll 
likely get two files that aren't byte-for-byte identical, so I can't 
just serialize the standard form and then deserialize the data into 
objects of my implementation.

Of course, my exposure to persistent storage has not included any 
concept of defining the stored version of data as part of the interface 
contract of the code.
If all 2d coordinates are stored as x,y in base ten ascii, then any 
implementation of a 2d coordinate could be used to recreate the data 
from disk.  Of course, this removes the opportunity for implementations 
to competie on the merits of space requirements, since all 
implementations have to produce the exact same file.
I'm not sure which would be the more valuable feature.

-Jason