Howdy all!

"David Griswold" <David.Griswold at acm.org> wrote:
> 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.

Ok, this is the "porting argument". That if we Squeakers start using
this new behaviour in Squeak programs those programs will not port to
dialects where this does not work.

Since no other implementations of removeAll: AFAICT exist in the vanilla
image (and I would guess are very rare even if we count "all Squeak code
ever written") I presume you are mostly referring to other Smalltalks
here.

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

Wait! You just said #removeAll: instead of #removeAll. We are still
talking about *adding* a method to Collection as (whoever started that
question) was stated above?

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

Well, if we add a method in Collection such classes are of course using
your vocabulary "broken" with respect to the new version of Collection.
But if we should care about that then we can *never* change any protocol
in Collection. We have to be able to evolve *all* parts of Squeak, even
if greater care should be taken for some parts.

I mean, are you arguing that we should never ever change anything in the
Collection hierarchy because something somewhere will break? Such
conservatism would IMHO be bad for Squeak. I mean, don't get me wrong,
the Collections are a nice piece of machinery but they are actually
messy and buggy in places if you look closely (as Richard have showed in
numerous ways).

One example of this (even though it is a newer addition not inheriting
from Collection, but it's in that category never) is SharedQueue which
has several bugs.

IMHO it is a mistake to place old code on a piedestal just because it is
old. :-)

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

Well, crash is a harsh word! :-) I interpreted it as "will possibly not
work" and given that interpretation I could NOT understand how adding a
method *in any way* can make old code "break". Changing behaviour of an
*existing* method like #removeAll: on the other hand can.

But sure, this might be the root of our misunderstanding.

> Cheers,
> Dave

regards, Göran