[BUG]Collection>>removeAll:

Richard A. O'Keefe ok at cs.otago.ac.nz
Mon Aug 26 22:31:53 UTC 2002


<goran.hultgren at bluefish.se> wrote:
	Why not add a #removeAll and utilize that as I and also Martin
	Wirblat (see below) propose?
	
Because I suggested it first and it isn't relevant to the point at issue.

	writing explicitly:
	
	x removeAll: x
	
	When the developer in fact MEANS "x removeAll".

Agreed.  I believe that in this thread it was I who first pointed out
that there should be some such method.  However, the obvious way to
IMPLEMENT the unary message #removeAll is

	Collection>>
	removeAll
	    "Remove all the receiver's elements and answer the receiver."
	    self removeAll: self.
	    "Or self removeAll: self copy if you have a buggy #removeAll:."
	    ^self

	And it gives us the ability to implement it efficiently in subclasses.
	
Agreed.  In fact, when you count the number of collection classes that _can_
support #add: and #remove: and their relatives, and the considerably larger
number of collection classes that _cannot_, the decision to put these methods
in Collection in the first place looks increasingly dubious.

Anyone read the paper about Smalltalk collections in OOPSLA 92?

	(Of course sometimes the developer does not intend "x removeAll"
	but it just happens that the collection sent in as a parameter
	is in fact x itself, so the check for identity in removeAll:  is
	necessary also.)

Exactly so.  _This_ is the battle I'm fighting, and it really doesn't
matter whether the code to be executed in the self == aCollection case
is a call to #removeAll or an invocation to the four angels a la
Katherine Kurtz, _whatever_ it is, there are people writing in this
thread who either insist that there shouldn't be any alias check at all
or that it should at most signal an error.

If there were a #removeAll, then having the alias check report an error
instead of producing the ANSI-specified effect might be OK.



More information about the Squeak-dev mailing list