#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.
in CodeLoader>>installSegment:

   (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

respondsTo: aSelector
      "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 mailing list