[FIX][KCP] KCP-0112-FixCanUnderstand [long!]
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Mon Dec 15 23:19:55 UTC 2003
Hi guys!
Julian Fitzell <julian at beta4.com> wrote:
[SNIP]
> When I call #subclassResponsibility I expect an error to be raised
> because that's what happens. I don't understand why anyone would expect
> anything else to happen... are you sure existing code really expects
> methods not to be called if they call #subclassResponsibility? That
> seems to me like a wholly incorrect assumption on the part of whoever
> wrote that code.
Yes, I have read through most of the postings (phew) and I can at least
say that the following scenario seems pretty "normal" to me:
1. I write an abstract class and mark the method #cleanUpTheMess with
"self subclassResponsibility" because it really needs to be implemented
by the subclasses, and I write a subclass Workshop that implements it.
2. Let's pretend Julian's code holds a bunch of objects that are
"potentially cleanable" and Julian decides to check using respondsTo:
that the message #cleanUpTheMess can be sent to them. All is well, the
ones implementing it get the message sent to them.
3. Some idiot creates a new subclass Kitchen and forgets to implement
said method. As it is now this will lead Julian's code to go BAM, he
will get a prompt error in his face saying that the method
#cleanUpTheMess should be implemented in class Kitchen, but isn't.
But... if we make respondsTo: "smarter" as has been proposed - this
mistake will go undiscovered! We will instead end up with messy
Kitchens! :)
So at least given this scenario I think I am on Julian's side.
These methods are written like this because if we ever end up in them -
then someone has botched it and we want to know about it! It means
either that the object is "missing" a method (subclassResponsibility)
given the expectations of the sender, or that someone is sending a
message to it that they really shouldn't send (shouldNotImplement) - the
last case implying that either the sender is just wrong - or the sender
is talking to a different object than it expects to be talking to. :)
There are perhaps tons of other subtle issues here (as the very long
postings on the subject seem to imply) - but I want to understand the
above scenario in the light of the new proposal before going into those.
;)
regards, Göran
More information about the Squeak-dev
mailing list
|