On 31 Jan 2014, at 12:57 pm, Quincey Morris
<quinceymor...@rivergatesoftware.com> wrote:
> On Jan 30, 2014, at 17:42 , Graham Cox <graham....@bigpond.com> wrote:
>
>> - (BOOL) respondsToSelector:(SEL) aSelector
>> {
>> if( aSelector == @selector(_processEndOfEventNotification:))
>> return YES;
>> ... [other code]
>>
>> }
>
> Shouldn’t this return NO for that selector? The NSObject documentation didn’t
> show this as part of the ‘forwardInvocation:” process. In fact, I wouldn’t be
> surprised if returning YES *disables* the ‘forwardInvocation:’ path.
>
I don't think it should be NO. In other cases where I've used the forwarding
mechanism, I return YES if I can forward to another object, and that works just
fine.
The documentation states:
"Note that if the receiver is able to forward aSelector messages to another
object, it will be able to respond to the message, albeit indirectly, even
though this method returns NO."
That implies that it doesn't actually matter what you return. To check anyway,
I changed it to NO and get the same result (unrecognised selector exception).
Setting breakpoints on my forwarding code, it's never called. I'm a bit puzzled
by this. So far, only the stub method approach seems to work.
> Incidentally, I originally envisaged that you would use NSStringFromSelector,
> rather than using @selector. Since, we’re hypothesizing, there’s an automated
> verification tool involved in the approval process, it might be that the mere
> presence of a private @selector compiled into your executable might be
> grounds for rejection.
>
I usually do selector comparisons using == and @selector(...). I do that a fair
bit, so if it's wrong, I need to know. Aren't these just comparing the
addresses of C strings in a big global table?
It's hard to know what the automated tool does. All I can say for sure is that
I've never been rejected for this particular usage. I have fallen foul of using
other private API once upon a time in other places, so it's not that the code
hasn't been run through the tool. In that case I was calling a private method,
not just stubbing one out as here.
I believe this usage is safe (for now), but certainly if a cleaner solution can
be found that would be great, because I know a few people are using this code
and I do too, and would like to continue doing so. The thought of going back to
opaque NSUndoManager gives me the willies.
--Graham
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
