Protocol conformance in extensions

[gregheo]

This is something Matt G. did in Swift by Tutorials that I liked. When you want to implement a protocol, I propose doing this as a class extension rather than adding it to the class declaration.

Rationale: keeps the class line clear, groups the protocol + its methods together, and can simply "add this code to the file" instructions by adding protocol conformance + methods in one shot.

See pull request for suggested text. You cannot declare properties in extensions so this is not great if part of implementing the protocol involves some closely related properties. But I think it's still worthwhile.

[cwagdev]

👍 I do this "in the real world" and love it. I do tend to keep related protocols together such as UITableViewDataSource and UITableViewDelegate though. I am not sure what the "rule" would be as far as that goes.

As far as a tutorial goes it makes for a lot less awkwardness, like you said you can instruct them to add the extension at the bottom of the file and not have to worry much about it being coalesced between random methods later.

[gregheo]

Hmm, I'm open to the idea of combining since some protocols do seem to go together. I like the idea of keeping data source and delegate separate since it shows a clear separation of concerns, but in "real life" most people do forget which methods are UITableViewDataSource vs UITableViewDelegate and in many cases it isn't really important.

Unrelated exactly, but – the downside of all of this is there's no compiler checking. If you put a data source method in the "delegate extension" that's perfectly valid! I don't think that's a dealbreaker since the idea is really just an organizational thing.

[rwenderlich]

I think this is a nice thing to put in the guide as it does look nice and make for clearer tutorials.

I would argue it would be easiest to make the rule "separate extension per protocol no matter what" so the rule is clear - yeah table view data source / delegate are frequently used together, but it's not very hard to split it up appropriately. So I'm happy with the text as-is.

[ColinEberhardt]

👍 for separate extensions for each protocol.

table view's datasource and delegate are conceptually quite different things, so to my mind should be separate! (although Apple does have a habit of being a bit fluid with the concepts)

[micnguyen]

Apologies for bumping this, but have others considered visibility of the Protocols when implemented as a class extension?

I agree that it does make things quite neat, but from a visibility perspective it's quite difficult to know if MyViewController conforms to UITableViewDataSource unless I check the file navigation to know that it even implements it. If it was in-line at the declaration of MyViewController, I know that it will implement the required functions and hence check the navigation for the pragma mark and jump there.

Consider the scenario where MyViewController is quite large, then one would not easily know what class conforms to what protocol unless they are diligent in checking the file navigation.

[RobertGummesson]

I see where you are coming from @micnguyen. I had similar concerns myself. But I must say that after I've gotten used to protocol extensions, the trade-off of keeping the code tidier makes it worthwhile.

From a visibility perspective, it can actually be an improvement to keep all protocol declarations separately. On top of always knowing where to find them (the bottom of each class in my case), it can make it easier to spot optional implementations.

Here is an example of a function list. Note the difference in the pragma mark indentation.