goran.hultgren at bluefish.se wrote:
> Hi all!
> 
> "Andrew C. Greenberg" <werdna at mucow.com> wrote:
> 
...
>>This code fails, for example, on a LinkedList.
> 
> 
> Yes, so I noticed when I tried to use removeAllSuchThat: on a
> LinkedList.
> But that is a bug in LinkedList (which really is a seriously weird class
> btw) since it clearly doesn't implement copy as should be expected
> according to ANSI, right? This is a quote from the standard on
> Object>>copy :
> 
> "Return a new object that must be as similar as possible to the receiver
> in its initial state and
> behavior. Any operation that changes the state of the new object should
> not as a side-effect
> change the state or behavior of the receiver. Similarly, any change to
> the receiver should not as a
> side-effect change the new object.
> If the receiver is an identity object, return the receiver."
> 
> regards, Göran
> 
> PS. All this talk about the ANSI standard makes my head hurt... Let's
> get back to some good old Squeaking. ;-) DS
> 


The problem with LinkedList is that in all (most?) other Collection classes, the collection is something else than its elements.
For LinkedList, the elements constitute the structure of the list, so the only "correct" way of copying a LinkedList would be to copy its elements.
Smalltalk copying in general is a difficult issue. Insisting that *all* classes obey the listed requirements won't work - it's just impossible.
The heart of the problem is at the definition of what is part of an object, and what is merely referenced by it.
What does "changing an object" mean when only its external behavior should be visible?

Looks to me like we would open another can of worms by relying on #copy semantics to get #removeAll: right.
Note that I do agree that using #copy would improve the behavior of #removeAll: in certain situations, but it just does not fix it for the general case - because IMO that's impossible.

Cheers,
Hans-Martin