[swift-evolution] Delegate Method Conventions

[plx]

> On Feb 3, 2016, at 4:55 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> Given all of these, perhaps the best that can be done at this time is to try and get the general guidelines such that for *new* delegate APIs it’ll be possible to give them Swift names that are guideline-conformant, but can still be exposed to Objective-C (where necessary) in an idiomatic way (e.g., has the arguments in the right ordering to be a delegate/datasource/etc. call in Objective-C).
>> 
>> But at least at this point I’m rather dubious there’s a worthwhile transformation out there that can be uniformly applied to the “SDK delegate/datasource protocols” and lead to an overall improvement.
> 
> You know, the `tableView(_:cellForRowAt:)` format has many disadvantages, but it *does* have a few good points:
> 
> - It's extremely distinctive and unlikely to collide with normal methods.
> - It clearly identifies not only that it is a delegate method, but which type it's associated with (through tableView).
> - It marks all the related methods so they stick together, even in an alphabetical list.
> 
> The only exception is with unary delegate methods, which may look like either `numberOfSectionsInTableView(_:)` or `controllerWillChangeContent(_:)`. There's not really a consistent format for them in Objective-C, and they often get separated from the other methods.
> 
> So perhaps the only transformation we should do is to make unary methods more closely match multi-parameter methods:
> 
> 	tableView(numberOfSectionsIn:)
> 	controller(willChangeContent:)
> 

This is a really nice idea.

At least offhand I can’t think of any problematic APIs, either.

> Then we can provide specific, separate guidance for delegates in the guidelines, justifying this format on the basis that the most important part of a delegate method is not actually what it does, but which type needs to call it.

I don’t know if I buy this justification, but I like the end result quite a lot.

> 
> -- 
> Brent Royal-Gordon
> Architechies
>