"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > > When you 'ultimately' dereference a package you do it by 
> > > UUID. However, there are only very few places where this
> > > is required. For everything 'inbetween' you should use 
> > > 'real objects' (PackageReferences) which allow
> > > you to think in whatever way is more convenient to you.
> > 
> > Or to put it an other way (provided I understood you correctly) - we
> > should use objects as "far" as possible and not rely on textual
> > descriptions.
> 
> Not quite. My point is that even when we write tools we are 'users'. If the
> systems makes it hard for us to get to convenient notions (names) then it's
> going to be a pain (and that's what Lex referred to). If names/ids are
> properly encapsulated this is much less of a hazzle.

Ok, I am obviously not seeing the light here. It seems to me there are
two possible scenarios, either you are using a tool that is "package
aware" and it can then simply let you choose a package/packagerelease
from a proper list. No UUIDs need to ever be viewed nor entered (and
that was what I meant).

...OR you don't have a "package aware UI" and then you may need to refer
to something textually - in that case it is nice if you can use
different means as long as you are aware of what you ar doing. Just
using a name will possibly not be reliable in the long run. Using the
UUID will be. Sometimes it doesn't matter and sometimes it really does -
like when describing dependencies. When it comes to dependencies I would
argue strongly for using UUIDs if it ever will be NEEDED to do it
textually. But still, I am arguing that tools should be available that
makes this unnecessary.

For example, referring to a package with a UUID-based URL (and
definitely not by using marvin.bluefish.se:8000 etc) like this is pretty
persistent:

http://map2.squeakfoundation.org/sm/package/2bbc04df-fc80-476d-9caa-6877
fa938bc2

While this is not as persistent:
http://map2.squeakfoundation.org/sm/packagebyname/sharedstreams

...but since we aren't describing dependencies it isn't as vital. Btw, I
have taken the approach of letting the name of the Package stay in the
Package object (and not have it in the PackageRelease objects). This
means that a package can change name but it will - at any given time -
have exactly one name. And any old name is forgotten.

> Cheers,
>   - Andreas

regards, Göran

PS. And of course the examples with the URLs had nothing to do with the
representation of dependencies.