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

Douglas Gregor dgregor at apple.com
Sun Jan 24 00:50:50 CST 2016


> On Jan 23, 2016, at 5:11 AM, plx via swift-evolution <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 <mailto: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
> 
> …where the rule is to find the “what is this method about” part of the selector, make that the name of the Swift function, and then label each argument as-necessary; the goal is for the methods to read as approximate natural-language sentences.
> 
> This is most definitely *not* in line with conventions, but I have found it to be *much* more readable overall; this is especially true in the case of new APIs (which don’t have the benefit of deep familiarity like the table-view and similar).

I’ve always found the delegate naming convention counterintuitive, because the important action is either in the second argument label or (when the source is the only parameter) buried in the base name.

In truth, I’d intended to investigate whether one could automatically translate Cocoa’s delegate methods into a form much like what you’re describing, but haven’t had time to experiment with it. Personally, I think it’s a promising direction to go, if we can come up with a guideline and implement some heuristics in the Clang importer to translate Cocoa well.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/d042d91c/attachment.html>


More information about the swift-evolution mailing list