SqueakMap default objects needs to be rehashed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SqueakMap default objects needs to be rehashed

Nicolas Cellier
Reply | Threaded
Open this post in threaded view
|

Re: SqueakMap default objects needs to be rehashed

Andreas.Raab
On 3/29/2010 3:36 PM, Nicolas Cellier wrote:
> See http://bugs.squeak.org/view.php?id=7485

Yup. Good call. The problem is deeper though. What we did was change the
hash function and as a result all the hashed collections that are
exchanged between images with different hash functions will fail.

A *perfect* example why ImageSegments are not a reliable long-term
storage btw. The bits are all the same but the interpretation of the
bits has changed (identityHash vs. scaledIdentityHash). Storing bits
without behaviors only works if you have tight control over both ends
(like in Croquet where we ensure identical code bases).


Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: SqueakMap default objects needs to be rehashed

Nicolas Cellier
2010/3/30 Andreas Raab <[hidden email]>:

> On 3/29/2010 3:36 PM, Nicolas Cellier wrote:
>>
>> See http://bugs.squeak.org/view.php?id=7485
>
> Yup. Good call. The problem is deeper though. What we did was change the
> hash function and as a result all the hashed collections that are exchanged
> between images with different hash functions will fail.
>
> A *perfect* example why ImageSegments are not a reliable long-term storage
> btw. The bits are all the same but the interpretation of the bits has
> changed (identityHash vs. scaledIdentityHash). Storing bits without
> behaviors only works if you have tight control over both ends (like in
> Croquet where we ensure identical code bases).
>
>
> Cheers,
>  - Andreas
>
>

Yes, that's why I call this workaround rather than fix.
It's fragile.

Nicolas