Hi!

Tony Garnock-Jones <tonyg at lshift.net> wrote:
> goran at krampe.se wrote:
> > Ehm, well, we already have one :) do "inspect it" on:
> > 	SMSqueakMap accountForUsername: 'tonyg'
> 
> That looks almost ideal, except that it bundles up a notion of identity 
> with a bunch of SqueakMap-specific stuff (eg. fields 'objects', 
> 'coObjects', 'map').

map is just a reverse pointer to the owner - the instance of
SMSqueakMap, typically you only have one in your image - that is the
full map.
objects and coObjects are two collections with all SMObjects that you
own and co-maintain.
 
> We should make something like SMAccount the thing that's attached to 
> changes in the system, instead of a string. Using a string seems really 
> old-fashioned and un-object-oriented - it's at the root of the current 
> discussion.
>
> Maybe SMAccount could be split into two classes: a separate developer-ID 
> object (which could live in the kernel since it'd not have a dependency 
> on SqueakMap) and the remnants of SMAccount that would reference the new 
> developer-ID object...

And how would it be referenced? :) The thing is that if you want to be
able to use Squeak without having the map inside the image - then you
will have to use some kind of textual or numeric id that can be remapped
when the SMSqueakMap structure is loaded into the image. And... right,
that is what we have today - the dev initials. :)

So unless you explain more specifically what you mean and what advantage
it gives us, I am not really seeing it.

One could argue that it should be possible to use Squeak and its code
tools (changesets and MC) without having SM in it - and then those tools
(future versions of them) would need to get your name and id from
somewhere else than the lookup into SM. And one could also think that it
should be possible to use Squeak without registering a public identity
on SM.

Perhaps then we could do this:

1. Add an object in the system representing "me". A little more than
just the dev initials. An object keeping at least full name, email and
dev initials. And perhaps a public key. This object can then be used by
changeset tools and MC etc in order to put more interesting info into
files that are exported out of the image.

2. When you have SM - our collective memory - in your image (typically
what 99% of us will have) then the above described object can easily be
mapped using the dev initials to the corresponding SMAccount and then
the system also "knows" your "SM-public" full name, email, key.

Perhaps this is what you were describing?

regards, Göran