[swift-evolution] [swift-evolution-announce] [Review] SE-0023 API Design Guidelines

[Dave Abrahams]

on Sat Jan 23 2016, plx <swift-evolution at swift.org> wrote:

>> On Jan 22, 2016, at 6:12 PM, Ross O'Brien via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> How would we apply this to delegate patterns?
>> For example, would we keep
>> tableview(tableView:cellForRowAtIndexPath:), or would we switch to
>> delegate(tableView:cellForRowAtIndexPath:) ?
>> Or perhaps better, for clarity over which protocol is being
>> conformed to / which property of the delegator is calling the
>> function:
>> dataSource(tableView:cellForRowAtIndexPath:),
>> delegate(tableView:didSelectRowAtIndexPath:)
>
> FWIW, I am personally favorable to a more radical-renaming for delegate methods, roughly the below:
>
> func numberOfSections(inTableView tableView: UITableView) -> Int // <- against guidelines, but symmetric
> func numberOfRows(inTableView tableView: UITableView, forSection section: Int) -> Int
> func cellForRow(inTableView tableView: UITableView, atIndexPath indexPath: NSIndexPath) -> UITableView

The interesting thing about delegate methods is that, for the most part,
use-sites don't appear in user code.  So *if* you're going to come up with
special conventions just for delegate methods you'd want to serve the
declaration site.  I don't know what these things *ought* to look like,
but the declarations above look to me like they've got an awful lot of
redundancy that doesn't help readability.

It's also worth asking whether the added complexity of special
guidelines for delegates pays for itself.


-- 
-Dave