New subject: [BUG]Collection>>removeAll:

29 Aug 2002

      "Andrew C. Greenberg" werdna@mucow.com wrote:
    *** The iterand of a #do:  on a collection, implicitly or
    otherwise, is undefined whenever the structure and contents of
    the collection is not invariant through the iteration.
That's all very well, but the *CALLER* of #removeAll: is NOT DOING ANY
ITERATION.  What gets iterated over, when, and how, is the responsibility
of the implementation of #removeAll:.
I have shown several implementations of #removeAll: where modification
of the receiver just plain doesn't happen during whatever iteration takes
place.
I fully and completely agree that when a programmer writes an iteration,
*THAT* programmer is responsible for making sure that the collection is
not changed.  But when someone calls #addAll:, they are not writing an
iteration.  It was the author of the #addAll: implementation who wrote
the iteration, and it was the author of the #addAll: implementation who
had the responsibility for making sure that it either worked or was
documented as not working.
This is a bedrock principle of the 
    Collection hierarchy's design, and seems to me a sound and reasonable 
    basis for proceeding.
I am in complete agreement with you.
THAT is why we know #removeAll: is broken.
To the extent that I have read what Richard has argued,
I would hope that a responsible arguer would have read all of it.
I am not convinced that #removeAll:  is or should be defined in
    the case of self.
In IBM Smalltalk, I'm told that it _is_.
Do you wish to argue that IBM Smalltalk should be changed so that it is not?
> And it really is very much an exaggeration to say that
    > "x removeAll: x copy" is an "accepted way" to empty a collection.
    > It is a way.  It is a good way.  But practically nobody knows about it.
    > It's what people do when they burn their fingers on "x removeAll: x".

    Just about everybody seems to know about it, IMHO, even late-comers to 
    the language such as myself.
You have done a survey of all Smalltalk programmers, have you?
If this were true, the thread would never have got started.
It _certainly_ isn't mentioned in _any_ of the Smalltalk textbooks I've
checked.  Surely if it's as well known as all that, _one_ of them would
have seen fit to mention it?
I have discussed this issue with several of the staff in this department,
including the head of department and the person responsible for 2nd year
data structures.  I have asked
"Given an abstract data type T that is some kind of container,
     with an operation
    remove_all_elements_of(x: T, y: T)
     explained as	
    'remove every element of y from x'
     what would you expect
    remove_all_elements_of(x, x)
     to do?"
The unanimous answer was "make x empty".
Ralph Johnson wrote a nice little piece I read early on in my
    Smalltalking life about common Smalltalk bugs, and the "copy
    trick" was clearly pointed out there.

How nice for you.  Tell me where to find it and I'll make sure my students
see it.
> I have also explained repeatedly not only _that_ the change makes the
    > specification simpler and cleaner, but _how_ it makes the specification
    > simpler and cleaner.

    Richard certainly has SAID that he feels it makes the spec simpler and 
    cleaner -- not all of us were satisfied either at the sufficiency or 
    correctness of his "explanation."  Merely stating, ipse dixit, that 
    something is so certainly does not evidence that it is so.

This makes me very angry.  I didn't just SAY that I "feel" it makes the
spec simpler, I wrote out in full what the specification _is_ right now
and what the specification would be if the bug were fixed.  I am not going
to do this again because this has already taken too much of my time.
No reasonable person could call comparing and contrasting the two versions
of the specifications "merely stating that something is so."
> Rational/critical debate at least requires a rebuttal of these points,
    > not a flat denial that no demonstration was ever made.

    Pot. Kettle. Black.

    Rational/critical debate at least requires acknowledgment that others 
    have made more than a flat denial when, in fact, they have undertaken 
    to make arguments on the merits.
No, once again you have made a FLAT DENIAL that I demonstrated that the
specification is simpler when the bug is fixed.
I have not found Ralph and 
    David guilty of empty gainsay, though I *DO* find Richard's present 
    "claim of victory by default" (but not his earlier arguments) to be 
    precisely that.

I have made no such claim.  Indeed, I am fighting desperately for reason
and safety in programming precisely because I do *not* feel that I have
any kind of victory.  It is not fair and not reasonable to attack me
for 'empty gainsay' for something I have not said or implied.
I am now far too upset to read the rest of the message.
To the people who have supported me in this, thank you.
Especial thanks to the person who pointed out that x removeAll: x
*does* work for OrderedCollections in IBM Smalltalk, so that the
nay-sayers are fighting to preserve a bug that at least one commercial-
quality Smalltalk does not share.  (Perhaps _because_ it is commercial
quality?)
To the people who have been watching quietly, thank you for your
bandwidth.  I hope we have all learned something.
To the others, well, thank you for provoking me to probe the issue.

Re: [BUG]Collection>>removeAll: