On May 31, 2008, at 1:22 AM, Russ McBride wrote:
Anyone want to take a stab at explaining to me as thoroughly as
possible why
[super respondsToSelector: aSelector]
doesn't actually do what it looks like it should do?
Bonus points if you can explain why I can override the
respondsToSelector:(SEL)aSelector method in my object and as long
as I include the above line at the end of my overridden version my
object reports back correctly that the object serves as a delegate
and the delegate methods get called appropriately.
It seems like either an infinite loop should occur if
respondsToSelector is really being called on self, or it should
return NO if it's called on super, in which case my delegate method
in self should never get called.
In general, sending a message to an object tells the Objective-C
runtime to search for the proper implementation of that method. The
search starts at the real class of the object and proceeds up the
inheritance chain through the superclasses. It invokes the first one
it finds.
Sending a message to "super" tells the Objective-C runtime to do the
same search, but start at the superclass of the class which defined
the method which is currently executing.
Now, if none of the classes in the inheritance chain have overridden -
respondsToSelector:, then the only implementation to find (in either
case) is the one provided by NSObject. That implementation always
behaves the same way -- it doesn't know and can't tell that it's been
invoked on super (nor from what class's code that might have happened
in). It just does what it's designed to do: it determines if "self"
responds to the given selector.
So, a message to super _doesn't_ do any of the following:
1) message a different object than self
2) cause self to masquerade as a more limited or restricted version
of itself (i.e. it doesn't actually change whether self responds to a
given selector, even temporarily)
3) invoke the implementation that's eventually found any differently
than normal (i.e. there's no hidden parameter which passes along
which class is "targeted")
It just starts the search for the implementation in a different
spot. If both searches (starting from self's real class or starting
from the superclass of the currently executing code) find the same
implementation, then the result is identical.
To do what you want, you can use [MySuperClass
instancesRespondToSelector:aSelector]. Note, you have to name the
specific class you want to check. You can't use [self superclass]
because that's dynamic -- the result from that may actually be deeper
in the class hierarchy than the code you're writing.
I hope that helps.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
