5
votes

I'm studying some basics about informal protocols and real protocols. What confuses me is, that Cocoa seems to use a lot of informal protocols on NSObject. Those informal protocols are categories on NSObject which declare methods, but do not actually implement them.

As far as I get it right, the only reason they make use of informal protocols (in other words, categories on NSObject that don't provide method implementations), is to give an autocompletion-hint in Xcode.

One example is the -awakeFromNib method defined in NSNibLoading.h, which is an informal protocol on NSObject. The nib loading system checks at runtime if an object implements that method. If it does, then it calls it.

But now let's imagine there was no feature called informal protocol. The alternative that would have the exact same effect would have been a real @protocol declaration which declares an optional method -awakeFromNib. NSObject would just adopt that protocol and the compiler would happily provide autocompletion.

Can anyone point out the big difference between these two strategies? I don't see the point of informal protocols but would really like to do so.

3

3 Answers

7
votes

Two huge differences:

  1. Compile time type checking. An explicit protocol with optional methods is much more clear about what methods you could implement. Both for explicitly adorning the class with the protocol it conforms too, and Xcode can provide much more precise code-completion lists of what you could implement.

  2. It keeps NSObject uncluttered. With the old style informal protocols all methods that are optional instead usually had their default implementation added to NSObject.

The informal protocols where a neat solution to a problem that no longer exist since the introduction of optional methods in protocols in Objective-C 2.0.

3
votes

The big difference is that the @optional keyword was only introduced a few years ago. For new code, informal protocols are basically obsolete. Much of the frameworks is non-new code.

1
votes

In order to use a protocol, you will have to import it, and let the object you are coding in conform to it

TestViewController : UIViewController <MyAwesomeProtocol>

In order for a category to be used, you do not have to do such things, you can simply import the category (which is not even required in all cases) and use the object (in my case a UIViewController) like you regularly would, and XCode would provide you with autocompletion for the category methods.

I prefer the protocol way, it is more strict and reliable. Categories tend to cause building issues and are a bit odd (in most, not all, cases) to be honest.