Richard A. O'Keefe wrote:

>I wrote:
>	>The question that (anObject respondsTo: aSelector) answers is
>	>    "Does anObject's class implement or inherit aSelector?"
>
>Nevin Pratt <nevin at smalltalkpro.com> replied:
>	Now wait a minute-- where'd you get that idea?
>
>In the normal approved Squeak way:  BY READING THE CODE!
>
>	You've just described the job of #canUnderstand:, *not* the job
>	of #respondsTo:.
>
>Have you read the implementation of #respondsTo: ?
>

Which implementation are you referring to?  The one in Object?  You 
actually read the comments?  My eyes usually just scan right past them, 
and I don't even notice if a comment is correct or not anymore.

Yes... that method comment is misleading.  It describes the 
implementation details as implemented in Object, rather than the actual 
responsibility of the method.  That's unfortunate.  And the wrong 
information for a comment to contain, in my opinion.

>If you will agree to "without throwing a MessageNotUnderstood
>exception or an Error exception saying that you should _never_
>send this message", then we agree 100% that that is what most
>of us _want_ to ask and what many of us _think_ #respondsTo: asks.
>
>I don't think that "self shouldNotImplement" counts as "responding"
>or that a body "self error: 'rhubarb rhubarb'" counts as "responding"
>in the sense that people care about.
>  
>

I agree.  My oversite.


>I repeat, it *never* tells me what *I* really want to know.
>

Well, *never* is a bit too strong.  And, that problem can exist with any 
message, not just #respondsTo:.  Just fix it.

>Given the intimate connection between #respondsTo: and #canUnderstand:,
>if one is overriding #doesNotUnderstand: and #respondsTo:, shouldn't
>#canUnderstand: be overridden too?
>	
>  
>

No, I don't think so.  The fact that Object>>respondsTo: uses 
#canUnderstand: is an implementation detail that nobody outside of 
Object>>respondsTo: should even need to know about.  In other words, 
from the point of view of external consumers, there is no connection 
between those two messages.

Also, consider that we need a message that asks if a method is in the 
method dictionary* of the receiver class, or any superclass of the 
receiver class.  And, such a message shouldn't care what messages are 
overrides.  It only cares about what is actually in the method dictionaries.

What do you propose the name of that message should be?

I propose #canUnderstand: for such a message, since that's what it does. 
 But I'm willing to entertain the idea that #canUnderstand: is 
inappropriately named, if you think you have a better name for that 
particular responsibility.

Nevin

*Actually, talking about "method dictionaries" as I did above is also an 
implementation detail.  Thus, that responsibility is better described in 
terms of classes including selectors, rather than if the method is in 
the method dictionary.  But we still need a message that asks for that 
information, and again, I propose #canUnderstand: to be the name of that 
message, just as I wrote above.

-- 
Nevin Pratt
Bountiful Baby
http://www.bountifulbaby.com
(801) 992-3137