On Tue, 20 Aug 2002, Norton, Chris wrote:

> What do you ANSI Smalltalk people think about this issue?  Has this been
> wrong since the dawn of Smalltalk?

FWIW, having taken the time to go look what the debate is actually about,
and then having thought about it a little, I find myself totally in
agreement with David Griswold.  Considering this method is identical in so
many Smalltalks (I haven't looked at VW, but I'm almost confident that...
;) and given that from my own experience the first question one must ask
when iterating over any collection is "is this collection stable under
this iteration (in the context of the given argument[s])?", then I believe
it should be considered "pragmatically correct" -- and any "error" that
might exist is indeed in the method comment which should include some
phrase along the lines of:

	"If aCollection == self then the result is undefined."

Otherwise we are starting to open a far larger can of worms than I think
anybody wants to deal with.  For example, I challenge ANYBODY on this list
to tell me (WITHOUT trying it and WITHOUT reading the code involved) the
behaviour and/or result of the following:

	| oc |
	oc _ OrderedCollection with: #foo.
	^oc addAll: oc.

(Small, and definitely alcoholic, prize in the bar at OOPSLA for the first
correct answer out of the hat.  [And if anybody comes up with the correct
answer, I _will_ know that they've cheated!])

While I concede that #removeAll: might just have a mathematically "sound"
solution (modulo identity complications), the #addAll: case is far worse.  
For one thing, the "correct" answer depends intimately on the semantics of
the underlying collection (much more so than in the #removeAll: case) and
reconciling correctness with performance in all cases is probably (i)
difficult, and (ii) highly undesirable (from pragmatic considerations).

Pragmatics aside, it's in the interests of portability (between Smalltalk
dialects, supposing just for a moment that the denizens of Pleasuredome
Squeak care about such things) explicitly not to rely on any particular
behaviour in such "degenerate cases".

Otherwise I will inisit that Jecel's "assignment is a binary selector" be
adopted and that in "ProcessorScheduler>>:= anObject" we test for
"anObject isNil" and raise a "BlueBookExampleForHumourOnly" exception
when needed.  Reductio Ad Absurdum, Batman!

Ian