CODEWITHSUNDEEP
iosobjective-cnsobject
CodaFi
CodaFi

Reputation: 43330

Must Protocols Conform To The NSObject Protocol?

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?

Upvotes: 20

Views: 6864

Answers (4)

Jake Lin
Jake Lin

Reputation: 11494

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).

Upvotes: 1

Rob Napier
Rob Napier

Reputation: 299325

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.

Upvotes: 22

Paul.s
Paul.s

Reputation: 38728

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

Upvotes: 1

Caleb
Caleb

Reputation: 124997

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.

Upvotes: 7

Related Questions