After-thoughts: my opinion is: Martin solution is more pragmatical : it is tailored for getting most improvment with minimal change in system. But formally, I prefer Andres design for it's clarity. - I do not like the idea that #identityHash and #primIdentityHash do behave differently - #scaledIdentityHash does clearly express itself on the contrary But that turns into german discussions ;)
Nicolas 2009/10/29 Nicolas Cellier <[email protected]>: > 2009/10/28 Stéphane Ducasse <[email protected]>: >> Martin >> >> are these changes related to the graphs you sent? >> I will have a look after my hospital check. >> Andres? Nicolas? >> Any feedback? >> Martin I imagine that I can package the changes :) >> >> >> Stef >> > > This has been pretty well explained by Martin and Andres. > The decision you have to make is : > > - choose Martin change, make speed improvment for most senders of > #identityHash, but eventually break a few senders and let package > maintainers fix it (example Magma) > - choose Andres change, assure 100% compatibility, let the > responsibility to package maintainers to use new message for improving > speed. > > In both cases, package maintainer might have to maintain different > branch for Squeak and Pharo, but I guess the solution would be adopted > soon in Squeak/trunk. > > I would tend to be conservative, but I recently took the opposite path > with #keys and #selectors in trunk, so I just can't give you my > personal preference, it's 50-50... > Whatever the choice, #identityHash usage is worth a review by package > maintainers anyway. > > Note that this is closely related to > http://bugs.squeak.org/view.php?id=1876 and > http://code.google.com/p/pharo/issues/detail?id=213 > Amazing the issue is still there when workarounds are known for so > long... So please do something! > > Nicolas > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
