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

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

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

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"bOtHeR," said Pooh, mistaking the LSD tablet for aspirin