Ok, I can prepare the checkpointed changesets for Martin's changes then. Stéphane Ducasse wrote:
Ok since there were some other discussions I think that andres and martin got a consensus on the solution (I had the impression that the one of martin was prefered). So as soon as the code is ok we will integrate that.
Stef
On Oct 29, 2009, at 10:39 AM, Nicolas Cellier wrote:
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 <nicolas.cellier.aka.nice@gmail.com>:
2009/10/28 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project .