[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