[BUG]Collection>>removeAll:

Travis Griggs tgriggs at keyww.com
Thu Aug 29 15:27:06 UTC 2002


goran.hultgren at bluefish.se wrote:
> 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?

Yes and yes. These are simple no brainers. If/when you have the more 
powerful version that actually works and doesn't freek the performance 
gurus out, then you can replace 1 with that.

> 
> 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
> 



-- 
Travis Griggs
Key Technology
10 2 letter words: "If it is to be it is up to me"




More information about the Squeak-dev mailing list