> > > That's an interesting way to look at the situation, but do note that
> > > most Smalltalkers will be suprised to find those assertions or
> > > corrections in removeAll:.  Most fooAll: methods just do: on the
> > > argument and foo: each element, and have no particular protection
> > > against #foo: modifying the argument.
> 
> What is this last statement based on? Is it the Squeak image?
> Using the MethodFinder and looking at all methods with "all:" I can
> actually not find many methods that " just do: on the argument and foo:
> each element"...
> 
> The only ones I found (a cursory look) where:
> 
> Collection>>addAll:
> Collection>>removeAll:
> CompositeEvent>>addAll:
> POSimplePolygon>>addAll:
> 
> And I also found that OrderedCollection>>addAll: and
> SortedCollection>>addAll: does NOT do that! Of course, what they do is
> equivalent to "just do: and foo:" but it is still different code.
> 
> Further I found quite a lot of methods named "somethingAll:" but the
> only thing I can see that they have in common is that they take an
> argument that is intended to be a Collection of something. That is all.
> 
> > Which, of course, concedes the point that fooAll: methods entail an 
> > implied iteration on its parameter.
> 
> Even if the statement was correct (which I do not agree with Lex, at
> least not if we look at the image) it would only show that most such
> methods where *implemented* that way. IMHO it doesn't "imply" anything.
> 

I've been programming Smalltalk for a while, and I know what the
implicitions are the same way I know what words in my native tongue
mean.  By itself, the "all" implies that the argument is a collection. 
If it's "fooAll:" where "foo" is a verb, and especially if there exists
a "foo:" method in parallel, then I stand by claiming that the
expectation is that the method will iterate over the argument and
perform a "foo" on all of them.

Your data actually agrees with this analysis.  I didn't mean to say that
the methods were *implemented* to literally use #do:.  In fact, a
primary reason to have optimized implementations of removeAll: is to get
rid of the explicit iteration.  Nevertheless, they will examine the
elements of the argument in some fashion.  It seems a very heavy burden
to require them to tolerate the argument changing as the method does
it's work.   As a general rule, experienced Smalltalkers will not expect
methods should to cope with their arguments changing while the method
progresses.  When they do, 

The ability to cope with such is extraordinary and often imposes a large
implementation burden.