Must Protocols Conform To The NSObject Protocol?

Question

The NSObject protocol comes with the stock protocol templates, but it doesn't appear to be all that necessary for actual implementations of the protocol. Leaving it out seems to change absolutely nothing. So, is it really necessary for a protocol to inherit from it, or is it just an unnecessary add-on?

score 22 · Accepted Answer · edited Oct 10 '14 at 09:11

For years I (and many like me) didn't make our protocols conform to <NSObject>. It works fine. But it can often be annoying. The most common annoyance is that you can't use respondsToSelector: without casting back to NSObject* (which kind of defeats the whole point of a protocol). That didn't matter back in the ObjC1 days because there was no @optional, so none of us worried about it (we didn't use protocols much at all in those days since without @optional they weren't that useful). Then ObjC2 came along with the wonderful addition of optional methods and suddenly respondsToSelector: mattered. It took a little while for the slower of us, but eventually we started to figure out that life was much simpler if you make your protocols conform to <NSObject>. Blessedly this has now made its way into Xcode, making it easier for everyone to do things in the more convenient way.

But no, you don't have to do it. It doesn't matter in many cases. But there's not much reason not to do it, so I recommend it.

Great answer ... But even the annoyance you are mentioning with NSObject protocol would only come into play with `id obj`, because if you reference the object with a class, the compiler will know the inheritance ... Which presumably starts with NSObject... — Grady Player, Oct 11 '14 at 21:52

score 7 · Answer 2 · answered Apr 06 '12 at 21:52

7

Not necessarily. A delegate is just a helper object -- the only requirements are those that the delegating class places on it. If you want to formalize the requirements for a given delegate, create a formal protocol, i.e. declare a protocol using the @protocol directive. If conforming to the NSObject protocol is one of those requirements, you can make your protocol adopt it:

@protocol MyDelegateProtocol <NSObject>
//...
@end

That said, I don't see any reason to create a delegate that's not derived from NSObject or perhaps NSProxy, and both those classes conform to the NSObject protocol already.

answered Apr 06 '12 at 21:52

Caleb

124,013
19
183
272

Could a delegate derived from NSObject break if the protocol doesn't conform to NSObject? (in other words, does not conforming in general cause delegate methods not to be called)? – CodaFi Apr 06 '12 at 23:10
2

Since NSObject conforms to the NSObject protocol, any class derived from NSObject also conforms to the NSObject protocol. So no, a delegate derived from NSObject won't break just because the delegate protocol that it adopts doesn't explicitly adopt the NSObject protocol. – Caleb Apr 07 '12 at 02:10

score 1 · Answer 3 · answered Apr 06 '12 at 21:54

Not every object has to subclass NSObject so I guess if you was expecting such an object to conform to your protocol it wouldn't necessarily have to conform to NSObject.

Conforming to NSObject let's the compiler know that the object conforms to the basics - check it out NSObject Protocol Reference. Without saying I conform to NSObject how does the compiler know I conform to any of this?

NSObject is defined as

@interface NSObject <NSObject> {
    Class   isa;
}

whereas id is defined as

typedef struct objc_object {
    Class isa;
} *id;

So for id the compiler does not know it complies to NSObject

score 1 · Answer 4 · answered Jun 29 '15 at 23:52

Recommend and not compulsory.

According to Apple's official document ProgrammingWithObjectiveC.pdf

If you attempt to call the respondsToSelector: method on an id conforming to the protocol as it’s defined above, you’ll get a compiler error that there’s no known instance method for it. Once you qualify an id with a protocol, allstatic type-checking comes back; you’ll get an error if you try to call any method that isn’t defined in the specified protocol. One way to avoid the compiler error is to set the custom protocol to adopt the NSObject protocol.

the protocol as it’s defined above is a protocol without conforming NSObject protocol.

As an example, it’s best practice to define your protocols to conform to the NSObject protocol (some of the NSObject behavior is split from its class interface into a separate protocol; the NSObject class adopts the NSObject protocol).

Must Protocols Conform To The NSObject Protocol?

4 Answers4