[BUG]Collection>>removeAll:

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Aug 29 16:18:49 UTC 2002


Hi all!

Ok, guys. Let's try to calm down and try to resolve this "storm in a
pond" (or whatever you say in english). I really like reading all the
arguments from all parties involved so far and I really think everyone
who has voiced an opinion have had good points.

Sometimes when I read Andrew I lean over to his side, but then reading
Richard (who really follow through the rhetoric with such detailed
logical reasoning and research it almost hurts my head :-) I lean over
to his side.

For anyone just jumping in here this is what I *think* is the current
"score":

- We all agree on that Collection>>removeAll: is currently in need of
*something*.
- I *think* we all agree on that adding a Collection>>removeAll would be
a nice addition, given a nice base implementation to fall back on and
some concrete implementations in subclasses.
- Some parties (including David Griswold and Andrew Greenberg and others
I presume) want us to simply add a check in the beginning of removeAll:
to see if the argument is == self and then signal an error.
- Some parties (including Richard O'Keefe and myself and others I
presume) would like to make this case instead "work". That would simply
translate into emptying the collection.
- What the ANSI standard says is not clear. We do know however thanks to
Allen Wirfs-Brock that the committe overlooked the case in question and
would probably (if given chance to correct it) opt to call it
"undefined". IMHO these two things together makes it uninteresting to
talk about ANSI in this case, and even if it was interesting Squeak is
by no means bound by ANSI anyway.
- Richard has proposed several variants of making it work including
using #copy. One variant I myself like is to simply call "self
removeAll" in this case and let that method deal with it as it please.
- We do know that there are at least two other Smalltalks behaving
differently so there is no given way to operate in order to be
"compatible" (In VW it fails, in IBM Smalltalk it works).
- Richard together with Jan Hylands has done some really interesting
archeological findings indicating that removeAll: indeed did work
earlier due to differences in #removeIndex:! And more efficiently too,
if I am not mistaken.

So the questions are (if anyone has forgotten):

1. Should we simply signal error or make "x removeAll: x" work by making
x empty?
2. Should we add a Collection>>removeAll with a base implementation and
suitable subclass implementations?

Personal current opinion:

1. Andrew had some nice arguments there for a while about "semantic
rules" on not changing operands during operation etc but in the end I
got swayed over back to Richard's side, *especially* after the recent
archeological findings, but also mainly because the "semantic rules"
seemingly to me should only apply when talking about iteration and even
though one way of implementing removeAll: is through a simple iteration
- that is not the only way to do it and the iteration is *inside*
removeAll: so it should not be a problem of the caller.

2. Adding removeAll is a good thing IMHO. Can't possibly see why having
to write "x removeAll: x copy" would be better - it can't be efficiently
reimplemented in subclasses and it is an obscure way of doing it.

As always, noone replies to my postings but I keep hammering them in
there... ;-)

regards, Göran



More information about the Squeak-dev mailing list