Re: performSelector:onThread:withObject:waitUntilDone:' not found in protocol(s)
Re: performSelector:onThread:withObject:waitUntilDone:' not found in protocol(s)
- Subject: Re: performSelector:onThread:withObject:waitUntilDone:' not found in protocol(s)
- From: Greg Parker <email@hidden>
- Date: Thu, 1 Apr 2010 10:42:48 -0700
On Apr 1, 2010, at 10:32 AM, Andreas Grosam wrote:
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.
The problem is that Objective-C protocols are immutable. There's no
way to add required methods to a protocol without breaking backwards
binary compatibility. If you did, older classes would claim to conform
to the protocol but may or may not actually implement the new required
methods.
It is possible to add new optional methods to a protocol, but then
you'd need -respondsToSelector: calls everywhere.
The upshot is that protocol NSObject includes only the most basic
operations, without anything that has been added to class NSObject in
the past decade or more.
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.
It would be possible to declare a new NSThreadPerformingObject
protocol that built upon the NSObject protocol. You could do this
yourself if you like. But even that would only work for one Mac OS X
version, because older OS versions had fewer thread perform methods
and newer OS versions will likely add more.
In practice, what you really want is an instance that does everything
class NSObject does, plus the delegate methods. The best way to write
that is:
NSObject<SomeProtocol> *obj;
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden