Hi Ragnar,

I had a similar problem when using sets with GOODS. (I used #includes: 
which sometimes worked and sometimes didn't). The problem is the 
following: GOODS treats sets like other objects by storing their 
instance variables (which is an array and tally for sets). When 
bringing sets back into the image, the array is restored as it was 
saved. But the implementation of sets depends on the order in which 
values are stored in the array. And the order depends on the hash value 
of the objects. Now, when GOODS reinstantiates the values of the sets, 
they are different objects and thus have different hash values!

I chatted with Avi and the simplest workaround we could think of is to 
send rehash when GOODS instantiates a set. That solves the problem but 
it is suboptimal: The rehashing modifies the set which then gets 
written back on each commit. This made the workaround for me unusable 
because too many write conflicts occurred.

I can send you the code for the workaround if you like.
If somebody has a solution I would be interested. For the moment, I 
just avoid storing sets in GOODS...

Cheers,
Adrian

On Jul 6, 2004, at 3:25 PM, Ragnar Hojland Espinosa wrote:

> I have anObj inside aSet that I pull out of GOODS, and that I want to
> remove.
>
> 	aSet remove: anObj
>
> This fails with Error: Object is not in the collection.
>
> This:
>
>      detected _ aSet detect: [:each | each = anObj ]
>      aSet remove: detected.
>
> does detect it (also with ==) but remove: fails too.
>
> This:
>
>      aSet _ aSet select: [:each | each ~= anObj ]
>
> works.
>
> Why is remove: complaining?
> -- 
> Ragnar Hojland - Project Manager
> Linalco "Specialists in Linux and Free Software"
> http://www.linalco.com  Tel: +34-91-4561700
>
>
___________________
Adrian Lienhard
www.adrian-lienhard.ch
www.netstyle.ch