Ralph Johnson <johnson at cs.uiuc.edu> wrote:
	But I think your "dead simple" fix is a horrible hack.

It is a principled technique of general utility:
 whenever you are about to do incompatible things to one object,
 do one of those things to a copy instead.

The question is not what the code looks like INSIDE,
but how simple the method is to use from the OUTSIDE.

	I do things like that sometimes, but always think it is
	something I should eliminate.

Oh, I'd put this on the "to refactor" list myself.  The important
thing is to get something that can be USED simply and safely.
Afterwards we can worry about how to make it simpler inside.

	It is just a patch for a special case, and one special
	case builds on another until the system is impossible to understand.
	
OK, what *are* the other special cases in #removeAll:?
Moving a special case from outside the encapsulation boundary
(when N thousand people have to worry about it)
to inside the encapsulation boundary (so that only one or two 
have to worry about it) seems to me like an excellent trade.

	I think we have a culture clash here.

Well, no.  What we have is a demonstration on one side that a small
change to a few methods makes their USE safer and simpler to understand,
and a bare assertion on the other side that there are lots and lots of
special cases which will make the code unreadable.

Where ARE these other special cases?

	I'm not sure just what the problem is, but when each side thinks
	that the other's model of elegant simplicity is a horrible hack,
	something interesting is at work.
	
I don't recall saying that the fix is ELEGANT, only that it is TRIVIAL.

OK is looking at the outside and saying "how hard is it to
understand how to USE this method" and "it was very easy to fix the
bug and the fix is very small."

RJ is looking at the inside and saying "how hard is it
to understand how this method is IMPLEMENTED" and "the patch just
handles one special case."

OK retorts "not working in that case was the bug that needed fixing".
	
Surely we agree that

 - a method where you DON'T have to worry about whether the argument is
   the same as the receiver is simpler and safer to USE;

 - an implementation which did not need special case code to handle
   argument == receiver would be a better implementation, mutatis mutandis;

 - a bug fix which obviously doesn't break previously working cases
   is nice to have;

 - a method which ACTUALLY has lots of special cases is something to
   avoid if you can reasonably provide one with fewer.

I can think of lots of special cases for removeAll: where you would want
to say "this won't work; don't do that."  At the moment, I cannot think
of any additional *meaningful* calls to #removeAll: that don't work, and
I have tried.  If I were aware of even more more kind of call to
#removeAll: that should work but currently doesn't, I'd regard that as a
signal to redesign #removeAll: *now*.