> Every Collection subclass has its own efficient algorithm for 
> "remove'em  all" (whether implemented or not).

I hadn't considered subclass implementations, very good point, however, 
if they had an existing #removeAll, putting one in Collection wouldn't 
affect them.  A quick check of my image shows only SkipList overriding 
my default #removeAll.

> OrderedCollection for example, has indices for first and last element, 
> so  why copy an OrderedCollection in #removeAll and waste memory and time?

OrderedCollection has no #removeAll, if a more efficient one can be 
implemented in it via it's indices, it could simply override the default 
implementation.  This doesn't seem a reason for a superclass not to 
provide a default implementation, if it can.

> And, have you tested (#(1) removeAll) or (#(1) removeAll: #(1)), they 
> are  Collections. How are these potential bugs avoided.

This is a very good point, I had considered this, but consider...

#(1) add: 3

Since collection has #add: and #remove:, and Array overrides them as 
inappropriate messages, this seems more a problem of Array having the 
wrong superclass, or more specifically, a problem of single inheritance 
being used to share the implementation.  Array is breaking the Liskov 
Substitution Principle.  Seems traits would be the fix here.  If a 
#removeAll method is ever appropriate, should it not be in the same 
class as #add:, #remove:, and #removeAll:, efficiency aside?  Not to 
mention that #removeAll: already exists on Collection, so these bugs 
already exist, adding a #removeAll doesn't create them.

> Sure, I understand your position. So the quesion is, which of the two  
> possible solutions must yield.
> 
> /Klaus

It's definitely something to think about, for now, I'll leave it, it's 
been in my image quite a while, and only SkipList overrides it with a 
more specific implementation.  I'm still using 3.8, it'll be interesting 
to see how 3.9 and it's traits refactorings on the collections affect this.