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 -respondsToSelector:
. -[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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…