goran.hultgren at bluefish.se wrote:
	The only ones I found (a cursory look) were:
	
	Collection>>addAll:			<- change already suggested
	Collection>>removeAll:			<- change already suggested
	CompositeEvent>>addAll:
	POSimplePolygon>>addAll:
	
Another "do:-and-foo:" is 
    SequenceableCollection>>
    atAll: indexArray putAll: valueArray
        indexArray with: valueArray do: [:index :value |
	    self at: index put: value].
	^valueArray

Following the rule "don't change what you are iterating over",
we see that this code assumes (self ~~ indexArray) & (self ~~ valueArray).
We might as well assert that:

    SequenceableCollection>>
    atAll: indexArray putAll: valueArray
	"Store the elements of valueArray into the slots
	 of this collection selected by indexArray and answer valueArray."

	self assert: [(self ~~ indexArray) & (self ~~ valueArray)].

	indexArray with: valueArray do: [:index :value |
	    self at: index put: value].
	^valueArray

	> Which, of course, concedes the point that fooAll: methods entail an 
	> implied iteration on its parameter.
	
I would like to go on record as saying that if you are a competent
programmer who takes encapsulation seriously, there won't be any such
thing as an "implied iteration" in code that is not intended to be
thrown away soon.

+ There will be methods whose explicit documented purpose is to perform
  an iteration.  You will pass such methods a block.  You will be able to
  observe intermediate states.  It will be your responsibility as caller
  to worry about aliasing and changes to the thing iterated over.

+ There will be methods whose explicit documented purpose is to compute
  some result from their arguments.  Any block you pass is likely to be
  an exception block.  You will not be able to observe intermediate states.
  It will be the implementor's responsibility to worry about aliasing and
  changes to anything that happens to be iterated over internally, unless
  the documentation *explicitly* passes the burden back to you.

- There WON'T be "implied iterations" where you are left to guess that there
  might be an aliasing problem.

For "block" read "block or selector and possibly an argument array" above.