[BUG]Collection>>removeAll:

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Aug 23 04:13:06 UTC 2002


Valloud Andres <Andres.Valloud at oya.state.or.us> wrote:
	When x == y, we have:
	
	I'd expect x to be left as it is, while x now doesn't contain any element
	that is in x.
	
	In other words, I'd expect x to be left alone *and* to be empty at the same
	time.  This only works on empty collections.
	
	We arrive at this nonsense because the collections are identical.  Similar
	arguments apply to addAll: and maybe others.
	
	The expressions x removeAll: x and x addAll: x are not a special case or an
	error condition: they are NONSENSE.  If they occur, the real problem is that
	the intentions of the program are nonsense as written by the developer.
	
No, they aren't nonsense.  A fair reading of the ANSI Smalltalk standard
(at least of the 1.9 draft) seems to require them to be accepted.

Partly the issue is that "the result is the collection passed as an argument"
is NOT a universal property of Smalltalk systems, and the ANSI standard says
the result is undefined.  Remember, all the Smalltalk textbooks I was able
to check said nothing at all about there being any result.

Also, you are IMPOSING a certain expectation, and then when the expectation
turns out to be unjustified, blaming (what turns out to be) the ANSI definition
instead of blaming your expectation.

MY expectation for
    x removeAll: y
is "x has all the elements in y removed; y is unchanged UNLESS IT IS x".
My expectations are not violated.

This difference means that neither your expectations nor my expectations
matter a single bean (Java or otherwise); we have a standard, we ought to
follow it if we can reasonably do so.

Let's take another example where it is really clear that an expectation
that the argument will be unchanged is quite unjustified.

    x := OrderedCollection new.
    x add: x.

Now, in the general case of x add: y where y is different from x,
x will change and y won't.  But that is NOT because add: doesn't
ever change its argument, it's because y happens to be different
from x.

If you do x add: x, then the receiver AND the argument both change.
This is perfectly legal, perfectly well defined, and perfectly
acceptable to squeak.

If having done (x add: x) we then do (x remove: x), once again
the argument changes, and there is nothing surprising or illegal
about this.

If the claim 'the argument doesn't change' has no foundation
for #add:, we cannot reasonably hold #addAll: or #removeAll:
to a standard that #add: and #remove: do not (and must not)
live up to.

In short, #removeAll: is being blamed for not agreeing with
expectations that have never been justified elsewhere in Smalltalk.
NOT a valid argument against conforming to the standard.



More information about the Squeak-dev mailing list