Sending a message to super
affects which implementation of that method we use. It doesn't change who self
is.
So let's try to imagine how respondsToSelector:
works. Given a selector mySelector
, it probably introspects every class up the superclass chain, starting with [self class]
, to see whether it actually implements mySelector
.
Now then, let's say your subclass is called MyTableView. When MyTableView says
[super respondsToSelector:targetSelector]
what happens? The runtime will look up the superclass chain for another implementation of respondsToSelector:
, and eventually will find NSObject's original implementation. What does that implementation do? Well, we just answered that: it starts the search for an implementation of targetSelector
in [self class]
. That's still the MyTableView class! So if you have defined moveLeft:
in MyTableView, respondsToSelector:
will find it and will return YES for moveLeft:
, exactly as you hope and expect.
Thus, to generalize, the only selector for which this search has been perverted is the search for selectAll:
- exactly as you hope and expect. So I think you can relax and believe that what you're doing is not only acceptable and workable but the normal solution to the problem you originally posed.
You might also like to look at the Message Forwarding chapter of Apple's Objective-C Runtime Programming Guide.