"Andreas Raab" <andreas.raab at gmx.de> wrote:

> You are missing the entire point of my message, namely that this is NOT an
> 'either or' situation. In other words:
> 
> > Suppose I email someone about a package -- should I 
> > use the name or the UUID?
> 
> I don't care the least bit! User either one. That's the whole point.

In some of the cases, I'd be compeled to use the UUID.  Specifically, if
I think my email will be archived and looked at later on, then I need to
use the UUID.  That's a pity, and a names-only scheme avoids this
situation.  People won't change package names very much if those names
are primary keys being widely used.

The wizadry I spoke of is, e.g., to allow this code to keep working even
when the package name changes:

	(PackageLoader packageIsPresent: 'Morphic') ifTrue:[...]

Nearly impossible wizadry is required to let me mention a package on IRC
while talking to someone who isn't using a Squeak IRC client, and expect
the reference to still work when they try it tomorrow.  Barring such
wizadry, which is just not going to happen in practice, people will be
using UUID's in at least some contexts.

You've described a well-implemented system that is based primarily on
UUID's.  Providing an interface to look up things by name does round off
one rough edge, but it doesn't avoid the fundamental problem.  If you
have UUID's at all, then it seems inevitable for them to leak into the
user's view in some circumstances.  You can't hide them as well as you
could if things stayed within a single object memory; package references
point across the Internet, they persist for years, and they show up in
contexts that are out of the control of any individual program.

But anyway, it's not that big of a deal.  It just seems like extra
engineering that makes things slightly worse instead of helping with
anything.  I'd certainly be pleased to use a featureful package
repository with dependency tracking,  whether it uses UUID's or not!


Lex