Namespace issues (was: Re: Intent)
Sat, 08 Apr 2000 21:00:57 PDT
>> 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
>> identities at link-time, replacing many unique strings with a single
>> instance, you can get something (e.g. reference to a signature),
>> is functionally equivalent to your UID, but one that is unique
>> 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.
>> internal representations between two functionally equivalent modules
>> will definitely not be 100% identical, you need to be able to store
>> actual name of the object, as opposed to the logical name, but I
>> 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.