[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