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

Reply via email to