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 <[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 >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
