34

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 <MyProtocol> foo; // foo here conforms to NSObject AND MyProtocol?

Just curious what the logic is.

Jonathan Sterling
  • 18,320
  • 12
  • 67
  • 79
Coocoo4Cocoa
  • 48,756
  • 50
  • 150
  • 175

5 Answers5

34

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.

Barry Wark
  • 107,306
  • 24
  • 181
  • 206
  • 2
    Why couldn't you just do "NSObject *variable"? Then you know it's derived from NSObject but also conforms to Protocol, then the compiler won't complain about retain and release. – dreamlax Mar 26 '09 at 01:29
  • Pratically, this is OK (as is casting to (NSObject*) before using any @protocol(NSObject) methods. Unless of course the instance is not, in fact, an NSObject. More importantly, declaring MyProtocol as implementing the NSObject protocol clarifies the intent of the protocol. – Barry Wark Mar 26 '09 at 17:48
  • 3
    If your protocol doesn't conform to NSObject, I find it preferable to use `id ` instead. One reason is that dynamic typing with `id` allows you to call any method the compiler can find a declaration for (without a warning), rather than just methods inherited from NSObject or declared in your protocol. This can be both dangerous and incredibly useful, depending on whether you're making safe assumptions. :-) – Quinn Taylor Jul 11 '12 at 00:13
29

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.

Lounges
  • 4,674
  • 5
  • 32
  • 43
24

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.

Alex
  • 26,829
  • 3
  • 55
  • 74
  • 6
    Nice. This is more relevant than the accepted answer these days as ARC removes the need for anyone to worry about retain/release. – Tim Potter Jun 13 '14 at 01:16
2

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.

Marc Charbonneau
  • 40,399
  • 3
  • 75
  • 82
2

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.

Ash
  • 21
  • 1