I have been seeing some code around that resembles the following:
@protocol MyProtocol <NSObject>
// write some methods.
@end
Is there any particular reason why MyProtocol conforms to the NSObject protocol? Isn't that rather redundant in that if you do something such as:
id foo; // foo here conforms to NSObject AND MyProtocol?
Just curious what the logic is.
I've never done that in my code, but I could see the advantage to it. If you pass a parameter as id <SomeProtocol> you'll need to re-cast it if you want to call any of NSObject's methods on that object.
I'm pretty sure the reason you would do this is to add the NSObject members (say like retain and release) to your protocol. Technically you can still send those messages anyways but you will get a compiler warning without it.
It's also very handy when you have protocols that have @optional methods (e.g. "modern" Objective-C 2.0 delegates often use this technique) If you don't include the NSObject protocol, you'll get warnings when you try to call respondsToSelector: on the object.
When you declare a variable like
id<MyProtocol> var;
the Objective-C compiler knows only about the methods in MyProtocol and will thus produce a warning if you try to call any of the NSObject methods, such as -retain/-release, on that instance. Thus, Cocoa defines an NSObject protocol that mirrors the NSObject class and instance methods. By declaring that MyProtocol implements the NSObject protocol, you give the compiler a hint that all of the NSObject methods will be implemented by an instance that implements MyProtocol.
Why is all this necessary? Objective-C allows objects to descend from any root class. In Cocoa, NSObject is the most common, but not the only root class. NSProxy is also a root class, for example. Therefore an instance of type id does not necessarily inherit NSObject's methods.
If you use any of the NSObject protocol methods such as retain, release, class, classname, the compiler will give you warnings unless your Protocol also includes the NSObject protocol.