#doesNotUnderstand: and #respondsTo: inconsistency

I found an inconsistency between the definition of #respondsTo:
and the common usage of it, for classes that implement
#doesNotUnderstand:

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?

Regards,
Martin

On 5/18/06, von Löwis Martin <[hidden email]> wrote:
> 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).

You are right.  One of the problems with #doesNotUnderstand: is that
changing it changes part of an object's behavior, but not all of it.
An object that handles a message with it is probably not considered an
implementor of that message.  It is easy to hack #doesNotUnderstand:,
it is hard to  change all the behaviors of the object to be
consistent.

-Ralph