Hi Levente,

> >> My questions related to this:
> >> - why does Behavior >> #hash rely on the name instead of identity?
> >
> > If you mean #identityHash, then its because involving an unstable
> > value in a #hash calculation is never a good idea.  #identityHash can
> > be different for the same class between two different images, or if
> > the class was ever becomed or reloaded into a new image, etc.
>
> Is there an actual user of that feature?

Several actually.

If your primary motivation is improving performance then we could
cache the hash value, possibly even straight in the CompiledMethod
itself (hard-coded).

But we _must not_ destroy stable and deterministic hashes.  It would
be a huge blow to existing users and even future potential
possibilities of future implementations of things.  Anything that
would try to share #hash calculations between images...  Possibly
Croquet.  It's easy to imagine some things!

MagmaDictionary is just a Dictionary except the internal array grows
on disk providing size scalability while sparing RAM.  The #hash of
the objects put into it are calculated by the clients -- it must be
consistent between users.

source.squeak.org uses a MagmaDictionary for the revision history.  It
was the best way to introduce the capability without invading
Monticello's code at all.

> Bob found out that #hash had been changed during the developement of
> Squeak 3.9. Therefore this issue is not present in Cuis (forked from 3.7).
> And I just checked Pharo and found that Behavior >> #hash had been removed
> from there.

I think that's a big mistake.  There's no need for us to cross the
line of a stable hash to a volatile one.  We can cache it.