[BUG]Collection>>removeAll:

David Griswold David.Griswold at acm.org
Thu Aug 29 22:27:35 UTC 2002


goran.hultgren at bluefish.se wrote:
> [SNIP]
> > > I'm sorry, just what is being proposed that would break
> > > existing classes?
> >
> > Changing the meaning of removeAll:.  It breaks all existing
> classes that
> > implement the Collection protocol or reimplement #removeAll:.
>
> I am sometimes pretty dense (and currently I am swaying
> between David's
> "assert proposal" and my own "calling removeAll proposal") but are you
> saying that making removeAll: returning a correct answer instead of
> garbage could break existing classes that rely on the garbage result?

No, I think there is a misunderstanding.  I'm saying something
different: changing #removeAll: so that it is required to work when
passed the receiver as an argument breaks all other implementations of
removeAll:, because as soon as you make that change, other
implementations suddenly no longer do the right thing in that situation,
and will have to be changed so that they handle this case, too.

> [SNIP]
> > > Again, with the possible exception of code that
> deliberately causes a
> > > DoesNotUnderstand, how would _adding_ a method to Collection
> > > "break" any
> > > other class?  Can you give an actual example?
> >
> > I just gave the example above: any other class that implements
> > Collection without inheriting from it, including your own class you
> > mentioned above.
>
> Now you are talking about breaking code not yet written. That is, code
> that will use the message #removeAll (in Collection "version 1.1") and
> which would not be able to polymorphically work with old classes that
> only implements Collection "version 1.0".

No, the code that breaks that I am referring to is not the unwritten
uses of the new semantics of #removeAll: that would fail.  I am talking
about the classes that reimplement the Collection protocol.  As soon as
Collection is changed in such a way that other classes no longer
correctly implement the protocol, those other classes are broken,
regardless of whether that brokenness causes a crash now, or in the
future.  I think we are just using the word "broken" differently- I
meant 'out of spec', and you thought I meant "actually crashes".

Cheers,
Dave





More information about the Squeak-dev mailing list