[BUG]Collection>>removeAll:

Stephan Rudlof sr at evolgo.de
Thu Aug 29 16:13:13 UTC 2002


Goran,

I'm replying ;-)


For me compatibility matters. So:

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.

Not exactly: I'm not against such an addition, but then it should be in a
protocol stating that it is *not* compatible with other STs. If the standard
says 'undefined' it means that you cannot expect compatibility here (and
reality agrees with my point of view).

Note (for Richard A. O. (correct shortcut?)): I don't bother about classes
far away the standard (e.g. Morphic stuff), but we are talking about the
*core* of Smalltalk/s.

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

Since this case is 'undefined' by the standard, it should raise an error.
Idea: raising an ANSIUndefinedException?

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

My assumption.

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

It's *interesting* to talk about ANSI here, if compatibility counts.

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

There is a way: just avoid using 'undefined' features. Then programs are
compatible for both (porting) directions. But to able to do so, you have to
*know*, that some feature is 'undefined' and therefore incompatible.

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

See other mail of mine subjected
  Place for efficiency improvement [was: Re: [BUG]Collection>>removeAll:]
.

> 
> So the questions are (if anyone has forgotten):
> 
> 1. Should we simply signal error or make "x removeAll: x" work by making
> x empty?

Signal error.

> 2. Should we add a Collection>>removeAll with a base implementation and
> suitable subclass implementations?

I'm not against this: but please in a protocol stating by its name that it
is incompatible with other STs, please.


Greetings,

Stephan

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


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3




More information about the Squeak-dev mailing list