site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com -- Greg Parker gparker@apple.com Runtime Wrangler _______________________________________________ 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... 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; This email sent to site_archiver@lists.apple.com