[FIX][KCP] KCP-0112-FixCanUnderstand [long!]
Julian Fitzell
julian at beta4.com
Mon Dec 15 19:58:17 UTC 2003
Peter van Rooijen wrote:
> From: "Nathanael Schärli" <n.schaerli at gmx.net>
[...]
>>Therefore, the code immediately breaks if it is used for a stream class
>>that either declares the method #close to be abstract (i.e., by
>>implementing it with the body 'self subclassResponsibility')
>
>
> I never understood this part of the argument. If we run into a self
> subclassResponsibility method, then the implementation of the object we sent
> the message to, is already incorrect, right? Why should we expect to be able
> to handle it well further down the line?
[...]
If you ask me, this is the crux of the argument that the rest of the
thread is missing. self subclassResponsibility is not really a meta
marker on the class - it's an error. It's implemented as:
subclassResponsibility
"This message sets up a framework for the behavior of the class'
subclasses.
Announce that the subclass should have implemented this message."
self error: 'My subclass should have overridden ', thisContext sender
methodSelector printString
Human beings can look at and see easily that to avoid that error,
they're going to need to define the method in their subclass. But the
point of it being an error is that it should never happen. If that
method gets called then there is a bug in the system and an error
*should* be raised. The fact that that method got called means there is
a problem in the system. And *that*, in my opinion, is the semantic
meaning the programmer intended when they wrote a method that called
#subclassResponsibility in the first place.
If we're going to say that objects don't respond to methods that call
these methods then we'd better do the same for #errorNotIndexable,
#errorNotIntegerIndex, #errorImproperStore, #caseError, etc... Perhaps
we should include methods that call #halt or #error: directly. Hmm -
what about ones that don't use any of they methods but create an error
class and signal it?
Ok, I'm getting silly but I think it makes a valid point. Just because
a method raises an error does not mean that the system should report
that the object doesn't respond to that method. And while I understand
that this is a special case hack because it only looks for methods with
non-conditional errors, it still feels like a special case hack and I
don't like that.
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.
Julian
More information about the Squeak-dev
mailing list
|