Nice find. So the reason for the change was to improve performance, but
now that change actually makes things slower.
hash function based on those could be 6x-10x quicker.
Post by Bob Arning
I'm neutral on this, but here is a bit more (and from earlier it would seem)
'From Squeak3.7beta of ''1 April 2004'' [latest update: #5963] on 22 June 2004 at 8:51:57 pm'
"Change Set:Â Â Â Â Â Â Â Â BehaviorHashEnh v1.2
Date:Â Â Â Â Â Â Â Â Â Â Â Â 22 June 2004, 16.02.2006
Author:Â Â Â Â Â Â Â Â Â Â Â Â Stephan Rudlof, md
md: added a line to the poscript to uncompactify the MethodProperties class. We want to add an instVar for the selector.
Improves the default Object>>hash forÂ Behaviors by installingÂ Behavior>>hash. String>>hash has been changed a little to avoid infinite recursion (without changing its semantics).
All is done in the postscript.
This is a special changeset: Do not export and import this changeset again after importing it the first time! Then the methods are not installed alone in the postscript anymore, leading to serious
Rationale: Object>>hash calling ProtoObject>>identityHash gives poor results forÂ Behaviors. Therefore a newÂ Behavior>>hash using Symbol>>hash or String>>hash (the latter slightly changed to avoide
infinite recursion) will be installed.
- It speeds up Set/Dictionary operations withÂ Behaviors a lot (see below).
- The main consequence for other objects asÂ Behaviors seems to be a changed hash if they use
Â Â Â Â self species hash
as a start value for computing their hash.
But AFAICS this doesn't hurt, since in most cases (non meta classes as species) it maps to Symbol>>hash, which is fast.
To make things more clear, the current implementation of Behavior >> #hash
- 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.
- 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
That's "one should not rename classes and expect things to work", isn't it?