Update after seeing your edit:
A class object responds to
respondsToSelector: just fine, as you’re probably aware. In a test application, I can do both of the following without any compiler warnings:
NSLog(@"Responds to selector? %i", [MyObject respondsToSelector:@selector(respondsToSelector:)]); NSLog(@"Responds to selector? %i", [[MyObject class] respondsToSelector:@selector(respondsToSelector:)]);
However, you’ve declared a protocol on your variable, so it assumes that the class object you’re pointing to implements those methods. The simplest solution would be to cast
someClass as an
id for the purpose of calling
respondsToSelector:. A somewhat cleaner solution would be to declare your own
@protocol which declares
+respondsToSelector:(SEL)selector, and then declare
someClass as follows:
Class<SomeProtocol, ClassRespondingToSelector> someClass = ...
Finally, be sure to file a bug with Apple at http://bugreporter.apple.com. Include a simple test application so that it’s very clear what you’re doing. They welcome such bug reports, even if they’ve been submitted in the past, as it helps them prioritize the fixes.
Final note: this is probably happening because in theory, you could have chosen to implement a root object entirely separate from NSObject, and in that case, it wouldn’t respond to
-[NSObject respondsToSelector:] is actually declared in the
NSObject protocol, not the class definition. The
NSObject protocol is actually where most of what you know as
NSObject actually lives. One could argue that
+respondsToSelector: should also be in there, but as of now, it’s not. And since you’ve provided a protocol list, and the method isn’t in there, it gives you a warning to make sure you know what you’re doing.