Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> "David Griswold" <David.Griswold at acm.org> is claimed by the authorities to have written:
> 
> > We simply disagree with you.
> Which 'we'? I'm certainly not in that camp. Take care when using the
> royal "we" - it can result in getting your head chopped off....

Yep. I do not count myself into that "we" either. I am "me". :-) :-)

> > Our failure to agree with you is *not* a failure to understand you.  As
> > far as I know no one has, as you have alleged, said that the overhead of
> > the check is too much or even a major issue.
> I seem to recall at least one suggestion that it would be so.
> 
> > It is just that the check
> > belongs in an assertion; that's just the right way to code these kinds
> > of checks.
> I disagree. Assertions (assuming we can agree that assertions refer to
> checks essentially used at compile/debug time rather than production
> time) will probably not provide sensible coverage for either this
> particular problem nor for the more general (and probably insoluble)
> problem.

Well, I am not sure I follow this. #assert: (in Squeak) is used in
TestCases (and other testcode) and in "run time" code too.
In the latter area I guess the idea is to make it more clear to
developers and to throw an AssertionFailure instead of just an Error or
something.

But I agree with Tim that we are not talking about "compile
time/debug/test" stuff here. Whatever.

> >  If you think that there is a need for a #removeAll method
> > that performs that function, that is an arguable but separate
> > discussion.
> A separate #removeAll for when you _know_ that you want to remove all
> the elements already in a collection is almost nothing to do with the
> real problem. The annoying problem is when you _unknowingly_ get screwed

It isn't?

> by an enumeration that messes with the collection itself. It is
> trivially easy to imagine code that results in 'a removeAll: b' when a
> == b because of other methods functions.

Yep, and then the #removeAll would kick in which handles the case and we
are all happy.
Can't see your point. I mean IMHO all of these cases should run
#removeAll  :

"x removeAll: y" (where x just so happens == y)
"x removeAll: x" (of course)
"x removeAll" (trivially)

And because removeAll easily can be implemented as a special case in
subclasses, as have been proposed for OrderedCollection as an example it
would also be fast..

> Just because there is no total solution one should not assert that
> nothing should be done to make small improvements.

So true!

Now... what about my proposal? :-)

regards, Göran