Hi all!

Stephan Rudlof <sr at evolgo.de> wrote:
> Goran,
> 
> I'm replying ;-)

Yiha! At last... I was almost starting to believe I was either being
ignored because of utter stupidity or my postings weren't getting
through... :-)

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

Good suggestion.

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

Sure, I agree. If we can then we should take care of showing where we
have added stuff beyond ANSI and other Smalltalks etc.

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

I assume your reasons are that you do not want people to write Squeak
code relying on such code working and then get slapped on their hands
when porting to other Smalltalks? That is probably the first reason I
really like. :-)

As long as we add removeAll then this is fine by me, otherwise it is
not.

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

I agree in principal with Richard saying that a standard should be read
"to the letter" and not based on anything else. But since obviously
different people interpret the standard differently we should *simply
because of that fact* choose the conservative error route. I think. :-)
I change my mind so often my head spins...

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

Well, of course. I was thinking more in lines of the fact that ANSI is
unclear. But given the porting argument above I can see the point.

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

Sure! :-)

> 
> Greetings,
> 
> Stephan

regards, Göran "changing his mind once again" Hultgren