performSelector:onThread:withObject:waitUntilDone: is a method on NSObject, not <NSObject>.
HTH,
Dave
On Apr 1, 2010, at 11:32 AM, Andreas Grosam wrote:
> 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 ([email protected])
>
> 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/davedelong%40me.com
>
> This email sent to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list ([email protected]) 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/archive%40mail-archive.com This email sent to [email protected]
