On Tue, 20 Nov 2018, Chris Muller wrote:
To make things more clear, the current implementation of Behavior >> #hash has two negative side effects:
- behaviors stored in collections relying on the hash value (e.g. Set,
Dictionary) will have to be rehashed whenever a behavior is renamed
- objects using Behavior >> #hash to implement their own #hash, like what
Eliot just did to Message will suffer from the same issue. So Sets and Dictionaries holding those kind of objects will have to be rehashed as well upon the rename of the behavior.
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?
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. So, I suggest we remove it as well unless there's a really good reason to keep it.
- do we want to fix those issues mentioned above or do we just say that
one should not rename classes and expect things to work?
Neither. We just say that when one renames a class to rehash all relevant HashedCollections.
That's "one should not rename classes and expect things to work", isn't it?
Levente
- Chris