[FIX][KCP] KCP-0112-FixCanUnderstand
Hannes Hirzel
hannes.hirzel.squeaklist at bluewin.ch
Mon Dec 15 17:29:40 UTC 2003
Hello Lothar
Lothar Schenk wrote:
> Am Montag, 15. Dezember 2003 13:16 schrieb Nathanael Schärli:
>
>
>>In fact, there were dozens of places deep in the core of the system
>>(e.g., in the Morphic framework) that caused a runtime error just
>>because I was being a good programmer and actually declared abstract
>>methods as 'subclassResponsibility', which is unarguably a good style of
>>programming.
>
>
> Whenever I hear someone say that something is "unarguably" so, it raises the
> itch in me to argue. :)
Question:
> Why is it 'unarguably' good style to fill abstract methods with the line "self
> subclassResponsibility"?
Answer:
Because this is an idiomatic convention in the Smalltaker subculture to
define a method as abstract; see Kent Becks book about Smalltalk idioms.
The point ot Nathanael is that he likes the system to have a way of
distinguishing between abstract and non-abstract methods. That's what he
means when he writes the following
<citation Nathanael>
And even though this may seem like a simple and good solution at a first
> glance, it introduces a lot of problems because this way of declaring
> abstract methods is not understood by the meta-protocol of the Smalltalk
> language. As a consequence, all the meta-functionality of Smalltalk
> (i.e., methods such as #canUnderstand: and #respondsTo:) thinks that
> such abstract or disabled methods are regular methods that are
> intended/expected to be called.
</citation Nathanael>
Even if Smalltalk is a relatively good language it does not mean that it
is the only one and that it couldn't be cleaned up or enhanced somewhat.
Between 1970 and 1980 every two years a new version of Smalltalk was
developed. Now we have 2003. Why not have a little clean-up?
In general OO software engineering circle the distinction between
abstract and non-abstract methods is considered to be a valuable
distinction. Lothar, I really do not see your point.
Cheers
Hannes
More information about the Squeak-dev
mailing list
|