Object: Identity vs. Environment
Nevin Pratt
nevin at smalltalkpro.com
Tue Jun 10 12:48:49 UTC 2003
Richard A. O'Keefe wrote:
>The question that (anObject respondsTo: aSelector) answers is
> "Does anObject's class implement or inherit aSelector?"
>
Now wait a minute-- where'd you get that idea? You've just described
the job of #canUnderstand:, *not* the job of #respondsTo:.
(anObject class canUnderstand: aSelector) answers "Does anObject's
class implement or inherit aSelector?"
I've *never* thought of #respondsTo: in those terms. It's got a
different job entirely. See below...
>The question that I'm always interested in is
> "Are there any cases where sending aSelector to anObject
> would not result in some kind of exception?"
>
>
In other words, can the receiver handle the message that was sent to it.
That seems to me to be the common sense meaning of #respondsTo: -- can
the receiver respond to the message sent to it, without throwing a
MessageNotUnderstood exception. And that's what I've always considered
the job of #respondsTo:. If it ever *fails* to do that, then it isn't
implemented correctly. At least, that's my view.
>I have disliked and avoided #respondsTo: ever since I realised that
>it never told me what I really wanted to know.
>
>
Yes, I have certainly noticed what I consider to be inappropriate
implementations of #respondsTo:, and that certainly does create a
situation where it doesn't tell you what you really wanted to know.
Relying on the default implementation of #respondsTo: when it really
should be overriden is one such case.
As a specific example (and, as I've posted before), if
#doesNotUnderstand: is overridden, then #respondsTo: should be
overridden too. This is just like the situation where #hash should be
overridden if #= is overridden. In both cases, they are inseparable
pairs that should be considered together.
But I've *never* thought that (anObject respondsTo: aSelector) should
answer "Does anObject's class implement or inherit aSelector". I use
#canUnderstand: for that. And if #respondsTo: isn't answering what it
should, I tend to want to fix it.
Nevin
--
Nevin Pratt
Bountiful Baby
http://www.bountifulbaby.com
(801) 992-3137
More information about the Squeak-dev
mailing list
|