[squeak-dev] Forward become and identity hash (was: The Trunk: System-bf.523.mcz)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Apr 14 19:45:31 UTC 2013


Ah, of course, class mutation is the opposite example, when the old object
becomeForward: the new one.
There would be a clever trick: keep the identityHash of the oldest object,
but that's certainly much too clever...


2013/4/13 Bert Freudenberg <bert at freudenbergs.de>

> On 13.04.2013, at 05:58, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
> Colin is right, whatever the choice and unlike become: we'll have to
> rehash something...
>
>
> Yep.
>
> And we must not forget that we always have to rehash ordinary (vs
> identity) Set/Dictionary , becomeForward: or not...
> Though, I would prefer the opposite behavior like Bert, because a frequent
> usage is to replace references to a new object with references to an older
> one, and IMO it's more conservative to preserve the older one.
>
>
> Here is the old discussion:
>
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-January/006970.html
>
> ... but I have to disagree with Dan on this one ;) The less surprising
> behavior is preferable, IMHO.
>
> - Bert -
>
>
> 2013/4/13 Bert Freudenberg <bert at freudenbergs.de>
>
>> Am 12.04.2013 um 23:47 schrieb Colin Putney <colin at wiresong.com>:
>>
>> On Fri, Apr 12, 2013 at 7:02 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:
>>
>>
>>> Maybe we should change the default?
>>>
>>
>> No, I think we'd just get subtle bugs of the opposite sort.
>>
>> Colin
>>
>>
>> Well, my mental model was that the become target would not change at all.
>> According to previous discussions, that is also how other Smalltalks handle
>> it.
>>
>> - Bert -
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130414/8cf7e763/attachment.htm


More information about the Squeak-dev mailing list