Hi all!

My postings in this matter seems pretty much go by ignored, but what the
heck - one more go!

"David Griswold" <David.Griswold at acm.org> wrote:
[SNIP]
> > Er, why should *THIS* change be subject to that stricture when so many
> > *other* changes have not been?  I mean, seriously?
> > 	I jumped into the conversation only because it seemed to me that
> > 	the necessary "due diligence" wasn't being done.
> >
> > But why for *THIS* change, when so many changes have been made to the
> > Collection classes without anywhere near this much debate?
> > Why not this
> > level of resistance to all the other things that have gone into the
> > Collection classes?
> 
> The other changes should have been subjected to this kind of discussion
> too.  Just because slapdash programming exists does not justify more of
> it.

Hmmm. I don't actually agree on this. Personally I think that Squeak
development currently suffers from integration bottlenecks and sometimes
an overly conservative view hindering improvements in especially "the
old" code.

I do not argue that we should simply hack away, but if we are to have a
discussion like this one (which I hope is a special case) for every
change in for example the Collection classes, then they will surely not
evolve much *at all*, IMHO.

[SNIP]
> As I have said repeatedly, I don't think any of your alleged three
> problems are actually real problems.  I think #removeAll: does conform
> to the ANSI spec, I think it is not an arbitrary restriction, but a
> common and universal one, I think the restriction has a lot to do with
> the semantics of the operation, and I don't think it is a consequence of
> a naive implementation- I think the implementation does the correct
> thing.

I assume you mean "...except that it does not signal an exception".
In that case I agree. But on the other hand I don't view ANSI compliance
as something undebatable.

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

That sounds weird to me. It seems to me that we are changing the
behaviour, period. We just can't have it returning garbage, can we?
Right. So even if we simply add an assert then we have changed the
behaviour, so in theory classes relying on the current garbage bug would
break. So what? To me this argument of "changing the meaning of
removeAll:" doesn't hold up as an argument for adding an assert *in
favour* of emptying the receiver.

I think that the single thing making this problem us to take so
different views is the fact that if the argument is == receiver there is
a chance for the receiver to make an "intelligent" decision. It can
realize that, hey - this must *mean* that I should remove *all* my
elements.

Thus there will be no iteration involved and no problem.

Note that I do not argue for Richard's variants making removeAll: use
copy or similar to make it work, because that would make this method
clearly different than most of the rest of these classes. (Though I once
again mention that removeAllSuchThat: does use a copy to make that
iteration work...)

Finally - I can say that if noone else than me favours my proposal then
I am *quite fine* with simply signalling an error. But then I surely
would like us to add #removeAll. Otherwise we still have this really
ugly, nonobvious, newbietrapping way of emptying Collections by using "x
removeAll: x copy".

> > *LOTS* of methods have been added to Collection that are not
> > supported by
> > classes that used to be reasonably good Collection mimics.
> >
> > I myself tried to write a class (EnumerationWrapper) that
> > looked a lot like
> > Collection without inheriting from it, and it was a really painful job
> > because Collection has a LOT of methods and many of them are
> > difficult to
> > impossible to put in other classes.
> 
> That is exactly why I think the Collection protocol should be minimal,
> especially in a system without mixins (which would allow people to never
> have to reimplement the whole protocol).  I think what you are saying
> actually supports my point that Collection should only be changed rarely
> and reluctantly.  If all those other methods weren't thrown in there,
> you would have had a lot easier time of it, and your code wouldn't break
> as often (as it will every time the Collection class semantics are
> changed).
> 
> You asked me for examples of classes that would break.  If the classes
> you wrote support remove, *your* code is a perfect example of the kind
> of code that will break.
> 
> > 	I'm not drawing a conclusion here, just trying to delineate
> > 	the crux of the issue.  I personally think removeAll
> > would be a nice
> > 	addition, but it would break some code out there, and
> > it's not used that
> > 	often (and shouldn't be), so I'm on the fence about it.
> >
> > 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".

To me this simply means that, yes, if we change a protocol, then sure -
old classes implementing the old protocol will no longer comply. But old
code can not possibly break.

Just trying to clarify a bit - it could still be argued that this kind
of breakage is unwanted - but personally I see such a stance more or
less as "don't change anything because someone might rely on it". Oops,
there went change down the pipe! :-)

regards, Göran