2012/5/9 Chris Muller <asqueaker at gmail.com>:
>> Why would you depend on the exact value of the identity hash?
>
> Not the value of the identityHash, the value of the hash.
>
>> When writing a new image and the identity hash changed, then obviously all dictionaries would have to be rehashed. Seems like a non-issue to me.
>
> That's the exact problem I want to avoid.  Think in the context of a
> multiuser client-server app accessing the same large persistent domain
> model.  The domain model includes a complex domain object used as a
> key in a dictionary, and one of the attributes used to determine its
> hash is one of its boolean attributes.
>
> Now, some of the clients suddenly happen to get a new #identityHash
> for true, which in turn changes its #hash.  Now they cannot access the
> domain's whose hash depends on true or false.  Worse, they might
> #at:put: into it and then the model is "corrupted" because there is no
> universally-consistent notion of true's hash across all client images.
>
> You're right, I could add my own private extensions, but we should
> consider having "universal" atomics given the the aforementioned
> insidiousness of the above situation..?
>

If this can only occur in this persistence scheme, then you obviously
require a #persistentHash.

Object>>persistentHash  ^self hash
True,False,UndefinedObject>>persistentHash ^some specific constant...

It is true that any other literal, arrays of such, or any hash-caring
object built of such would be cross-image hash-persistent...
So we are very close to it.

But YAGNI, your hash sounds hackish...
Maybe your own image tracer could implement the hack too ?

Nicolas