site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com I get this warning "performSelector:onThread:withObject:waitUntilDone:' not found in protocol(s)" when the receiver of the message is declared as: id <SomeViewDelegate> viewDelegate; and SomeViewDelegate is declared as a protocol: @protocol SomeViewDelegate <NSObject> ... @end for example: - (void) foo { if (viewDelegate && [viewDelegate performsSelector:@selector(someMethod)] { [viewDelegate performSelector:@selector(someMethod) onThread:[NSThread mainThread] withObject:nil waitUntilDone:NO]; } } The cause of this is because the mentioned selector is declared in a Category and not in a protocol: @interface NSObject (NSThreadPerformAdditions) - (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait modes:(NSArray *)array; - (void)performSelector:(SEL)aSelector onThread:(NSThread *)thr withObject:(id)arg waitUntilDone:(BOOL)wait; ... @end Unlike the above methods, the following methods are defined in a protocol NSObject: @protocol NSObject ... - (id)performSelector:(SEL)aSelector; - (id)performSelector:(SEL)aSelector withObject:(id)object; - (id)performSelector:(SEL)aSelector withObject:(id)object1 withObject:(id)object2; ... @end This seems to be a conceptual flaw caused by the use of categories. How do I get rid of this warning without casting the receiver to id? Well I know -- it's a rhetoric question ;) -- the next question is more relevant: Why is there no "NSThreadPerformAdditions" *protocol*? I see a clear advantage when using protocols over categories. Is there a compelling reason to still use categories in a more or less stable framework in order to expose interfaces? Categories deliberately group interfaces (and implementation) into related sections. However, IMHO they do not serve well as a concept for interfaces. Especially, if they extend a given class which definition may be stated anywhere. So, I consider categories are more or less a "private" extension for a given class, which can be used by clients only if they know of this special extension and when they have access to the headers where the category is defined. And, when the clients don't use "abstract interface concepts" (like @protocols) - for example when using delegates. IMO, categories are not well suited to be used as a general interface concept. Protocols do this. Having said this, I do think, the performSelector:onThread and performSelectorOnMainThread methods should be declared in a protocol - and not just within a category. What does it mean, when the compiler does not find essential methods related to NSObject within the protocol NSObject? We could say, this means for the compiler (and us?) these methods do not "officially exist" for an instance of NSObject, since the NSObject protocol does not define them. Well, they are defined in a category - but they do not belong to the "base definition" of the class, and do also not belong to another protocol. To be frank, this seems to create a mess. Although I understand that many Objective-C veterans don't expect that intensive help from a compiler, but rather prefer the flexibility and trust on themselves when it comes to "type safety" or duck typing. However, I cannot fully agree. IMHO, the missing methods, and also possibly many other, should be declared in a protocol. This would solve elegantly any problem when using abstract interfaces (@protocols). To be honest, I could imagine that it would be beneficial if the host of methods declared in any interface of the many classes were declared within a protocol, as well. What's your opinion on this? Thanks in advance Regards Andreas _______________________________________________ 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/site_archiver%40lists.apple... This email sent to site_archiver@lists.apple.com