goran.hultgren@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
Howdy all!
"David Griswold" David.Griswold@acm.org wrote:
goran.hultgren@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
Hi again!
goran.hultgren@bluefish.se wrote:
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
Well, for pathological correctness I should of course acknowledge that adding a method which "blocks" a method with the same name in a superclass could break old code.
Btw, since we obviously are "stuck" when it comes to making removeAll: "work" could we agree on the following changes at least:
- Add a #removeAll implementation in Collection, category undefined. Comment stating it being non ANSI. - Add concrete implementations of the same in suitable classes - Do the identity check and signal an error in removeAll:
If nobody objects perhaps someone could whip up a changeset for public review (before smacking it up as a FIX).
Then Richard's new findings in removeIndex: need to be followed up for performance reasons, but that is another story.
regards, Göran
PS. I haven't seen any postings from Doug Way in a looong time, are you out there Doug? :-) DS
squeak-dev@lists.squeakfoundation.org
-
David Griswold -
goran.hultgren＠bluefish.se