[swift-evolution] Delegate Method Conventions
plxswift at icloud.com
Wed Feb 3 17:06:07 CST 2016
> 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:
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
More information about the swift-evolution