Peter van Rooijen wrote:
From: "Nathanael Schärli" n.schaerli@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