Tim Rowledge wrote:
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [BUG]Collection>>removeAll:
> Reply-To: squeak-dev at lists.squeakfoundation.org
>
> "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....

Please believe that I try to be careful with my "we"s.  Let people speak
for themselves- and lo! some have, by publically saying they agree on
this list.  That is the only we I am talking about; "we who've said we
don't think #removeAll:'s semantics are broken", is how I would put it.
I assure you I wasn't accidentally including you.

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

You would have to support your assertion that assertions would not
provide sensible coverage.  You can always leave them on, you know, if
you want, but let me turn them off, when I want.  To anyone who told me
these sort of checks are useful because they see them fail in production
often, I would tactfully suggest that they might want to worry more
about the reason why *that's* happening.

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

Yes, it is easy to imagine such code- but it is the programmer's job to
avoid writing it.  The last thing we want to do is *sanction* it.
Whenever it happens, a programmer failed somehow in their understanding
of the system, and it is important for that to cause notification, so
the programmer pays attention, because the design needs to be looked at.
Just handling it silently (even in development) and going on your merry
way with a demonstrably broken understanding of the system is not such
an obviously good thing as it might appear.

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

I *am* suggesting improvements.  But changes to the semantics of
#removeAll: are not among them.

Cheers,
-Dave