A history of ideas: 'subclass responsibility'

Dear Smalltalkers,

For a piece of research I am currently working on, I have been
reviewing the arsenal
of publications on the genealogy of Smalltalk(s) for some hints on the
origin of the
Smalltalk-specific "subclass responsibility" approach, i.e. the
Smalltalk dialect for "abstract object-classes",
roughly speaking. I am particularly interested in references to design
decisions. It would be particularly enlightening
whether the Xerox crew was aware of the "virtual quantity" feature
introduced in Simula-67 and their perception. I do have thoroughly
studied "original" Smalltalk-related contributions, far beyond the
Blue Book, but could not find explicit references beyond the mere fact
that this is the Smalltalk way of doing it; but why? Note that I am
well aware of more recent discussions on that very matter, especially
in the Squeak community on the semantic consistency of
subclassResponsibility etc.

Is anybody aware of some nuggets out there? I would be grateful for
any hint ...

Best,
//stefan

Stefan Sobernig wrote:
> Dear Smalltalkers,
>
> For a piece of research I am currently working on, I have been
> reviewing the arsenal
> of publications on the genealogy of Smalltalk(s) for some hints on the
> origin of the
> Smalltalk-specific "subclass responsibility" approach, i.e. the
> Smalltalk dialect for "abstract object-classes",
> roughly speaking. I am particularly interested in references to design
> decisions. It would be particularly enlightening
> whether the Xerox crew was aware of the "virtual quantity" feature
> introduced in Simula-67 and their perception. I do have thoroughly
> studied "original" Smalltalk-related contributions, far beyond the
> Blue Book, but could not find explicit references beyond the mere fact
> that this is the Smalltalk way of doing it; but why? Note that I am
> well aware of more recent discussions on that very matter, especially
> in the Squeak community on the semantic consistency of
> subclassResponsibility etc.
>
> Is anybody aware of some nuggets out there? I would be grateful for
> any hint ...
>
> Best,
> //stefan

[ Caveat:
No nuggets here - just a brute-force-and-ugliness attempt
to answer. You might be fishing way upstream from here.
]

The short answer to "Why this way?" is "Because we can."

Seriously - it just works out.

I'll just walk us through the result,
the "Why" part follows naturally.
(To me, anyway.)

Create a subclass of your AbstractClassNamedWhateverThing,
call it UnfinishedButConcreteNamedWhateverThing.
Don't add any methods to it.
Create anInstanceOfUnfinishedButConcreteNamedWhateverThin g.
Send said instance the message in question.

An error ensues.

As part of handling the error, in addition to everything
else that must be done, something, somewhere, will need
to produce an error message, and wherever that place is,
aWriteStream will be written to, effectively something like:

name := message receiver class name.
prefix := ('aeiou' includes: name first )
ifTrue: ['an']
ifFalse: ['a'].
ws
nextPutAll: prefix
; nextPutAll: name
; nextPutAll: ' doesNotUnderstand: '
; nextPutAll: message selector.

which, in this case produces the equivalent of:

'anUnfinishedButConcreteNamedWhateverThing'
, ' doesNotUnderstand: '
, '#subclassResponsibility'

Now, back to your question - why this way?

Because we also need a way to respond
for the general case of a message received
that is not understood.

Having already solved the general case,
we can solve the specific case of an incomplete
concrete subclass by marking the 'required', but
unimplemented methods of the abstract class,
with a redirect to the method
#subclassResponsibility
the latter of which is simply never implemented,
hence the result described above.

Having arrived at this point,
one eventually realizes that another 'interpretation'
of the #subclassResponsibility message is this:
Any class which sends
the #subclassResponsibility message
is by definition an abstract class.

So you see - the "why this way" follows naturally.
Call it "emergent behavior", if you like.

---

If you meant something else, er, sorry.
You might want to try defining
a class named 'Responder', creating
an instance thereof, to which you then
send the two messages
#virtualQuantity
and
#whatYouWereAfter.

(In light of the above).

Regards,

-cstb

Using #subclassResponsibility has the side effect of making #implements:
difficult to use or interpret. For example, even if

anObject implements: #foo

returns true, it may not be safe to send

anObject foo

because it could implement #foo as

self subclassResponsibility.

Whether or not it's good style to use #implements: is another
discussion. For example, VisualWorks rarely if ever uses it, but I have
seen it in a commercial application. The usage I remember was bizarre
and led to unexpected results, one of which was to delay my departure
from work one day by several hours.

cstb wrote:
> Stefan Sobernig wrote:
>> Dear Smalltalkers,
>>
>> For a piece of research I am currently working on, I have been
>> reviewing the arsenal
>> of publications on the genealogy of Smalltalk(s) for some hints on the
>> origin of the
>> Smalltalk-specific "subclass responsibility" approach, i.e. the
>> Smalltalk dialect for "abstract object-classes",
>> roughly speaking. I am particularly interested in references to design
>> decisions. It would be particularly enlightening
>> whether the Xerox crew was aware of the "virtual quantity" feature
>> introduced in Simula-67 and their perception. I do have thoroughly
>> studied "original" Smalltalk-related contributions, far beyond the
>> Blue Book, but could not find explicit references beyond the mere fact
>> that this is the Smalltalk way of doing it; but why? Note that I am
>> well aware of more recent discussions on that very matter, especially
>> in the Squeak community on the semantic consistency of
>> subclassResponsibility etc.

etc.

Some dialects use #respondsTo: instead of
#implements:. In my view the former is better
semantically, since it doesn't seem to
promise that the response could not be
a #doesNotUnderstand:.

You can "implement" something, but
"implement correctly" is a different thing.

I think it should be up to the (application-)
programmer to implement a method like
#implementsCorrectly:. Or at least for them
to understand that if they did not implement
it themselves, they can't rely too much on
its results.


-Panu Viljamaa




Bruce Samuelson wrote:
> Using #subclassResponsibility has the side effect of making #implements:
> difficult to use or interpret. For example, even if
>
> anObject implements: #foo
>
> returns true, it may not be safe to send
>
> anObject foo
>
> because it could implement #foo as
>
> self subclassResponsibility.
>
> Whether or not it's good style to use #implements: is another
> discussion. For example, VisualWorks rarely if ever uses it, but I have
> seen it in a commercial application. The usage I remember was bizarre
> and led to unexpected results, one of which was to delay my departure
> from work one day by several hours.
>
> cstb wrote:
>> Stefan Sobernig wrote:
>>> Dear Smalltalkers,
>>>
>>> For a piece of research I am currently working on, I have been
>>> reviewing the arsenal
>>> of publications on the genealogy of Smalltalk(s) for some hints on the
>>> origin of the
>>> Smalltalk-specific "subclass responsibility" approach, i.e. the
>>> Smalltalk dialect for "abstract object-classes",
>>> roughly speaking. I am particularly interested in references to design
>>> decisions. It would be particularly enlightening
>>> whether the Xerox crew was aware of the "virtual quantity" feature
>>> introduced in Simula-67 and their perception. I do have thoroughly
>>> studied "original" Smalltalk-related contributions, far beyond the
>>> Blue Book, but could not find explicit references beyond the mere fact
>>> that this is the Smalltalk way of doing it; but why? Note that I am
>>> well aware of more recent discussions on that very matter, especially
>>> in the Squeak community on the semantic consistency of
>>> subclassResponsibility etc.
>
> etc.