Object: Identity vs. Environment
Nevin Pratt
nevin at smalltalkpro.com
Wed Jun 11 13:26:04 UTC 2003
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
More information about the Squeak-dev
mailing list
|