On Wed, May 9, 2012 at 1:46 PM, Chris Muller <asqueaker at gmail.com> wrote:

> > 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.
>

How so?  Given that within an image the hash and dictionaries hashed
there-on are consistent how does it matter if two different images have
different hashes and different hash values? How do these clients suddenly
acquire new hashes for nil, true and false? Smalltalk systems have been
like this for many decades and have not found this to be a significant
problem in practice.  There ca be performance advantages with consistent
hashes (e.g. of symbols, avoiding having to rehash method dictionaries on
code load).  But no fundamental problem.

BTW, there are even lisp systems that use an object's identity as its hash
/and/ have moving garbage collectors so that all identity-hashed
collections are rehashed after gGC.  These systems keep working too, even
though an objects' hash changes through its lifetime, let alone differs
between systems.


> 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..?
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120509/a2e617d5/attachment.htm