#doesNotUnderstand: and #respondsTo: inconsistency
von Löwis Martin
Martin.vonLoewis at hpi.uni-potsdam.de
Thu May 18 16:20:52 UTC 2006
I found an inconsistency between the definition of #respondsTo:
and the common usage of it, for classes that implement
The name "respondsTo:" suggests that it should return true
if the receiver gives a result when that message is sent.
Indeed, most usages of respondsTo: check it in order to
find out whether the message will be understood, e.g.
(contentStream respondsTo: #close) ifTrue:[contentStream close].
Now, if the class defines #doesNotUnderstand: in order to understand
more messages, this usage breaks unless respondsTo: is updated
accordingly (which it never is, in Squeak).
For example, HtmlEntity implements #doesNotUnderstand: in order to
provide arbitrary getters and setters for attributes (e.g. you
can do "anAnchor href: 'http://www.squeak.org/'). To match that
extended functionality, HtmlEntity should (IMO) also define
"Extend the respondsTo: super implementation to also include
arbitrary attribute getters and setters."
(aSelector numArgs <= 1) ifTrue: [^ true].
^ super respondsTo: aSelector
What do you think?
More information about the Squeak-dev