Nicolas,

Would you like Martin's approach better if the selector was 
#basicIdentityHash instead of #primIdentityHash?  Is it a matter of 
naming only, or is there something else?

Andres.

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