I understand it is good practice to pass self
to all delegate method calls, like UIKit does with UITableView for example.
What is your recommendation for naming them?
Examples:
func didSelectName(forNamePicker: NamePickerViewController, name: String)
or maybe
func didSelectNameForNamePicker(namePicker: NamePickerViewController, name: String)
or maybe simply
func didSelectName(namePicker: NamePickerViewController, name: String)
This makes more sense to me
func didSelectName(name: String, forNamePicker namePicker: NamePickerViewController)
I also think it depends on what this method is doing and in what context it defined.
Well, this is your typical delegate method, it belongs to the NamePickerViewControllerDelegate, and it notifies the delegate that the user picked a name.
I like your version, I will start using it.
I think this would be a nice addition to the style guide (I haven't seen it in the current version but noticed a massive PR pending).
Here's my take:
(1) This guide frequently defers to Apple's guidance. For examples, see Naming
and Protocol Naming
sections, both of which refer to Following Apple's API Design Guidelines
.
(2) Apple frequently puts the name of the delegating (i.e. self
) object _first_. UITableViewDataSource
and UITableViewDelegate
show _many_ examples of this:
optional public func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell
optional public func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath)
(3) Thereby, if we specify anything (I'm on the fence about whether we should or not), I think we should follow said examples. Thereby, I'd go with this signature:
func namePickerView(namePickerView: NamePickerView, didSelectName name: String)
Right. I think this is going to look like this for Swift 3, since the first parameter will no longer be handled specially like in Swift 2.2.
func namePickerView(_ namePickerView: NamePickerView, didSelectName name: String)
Doing the same thing that table view source is a good naming strategy.
Understood. Thanks for the clarification. @JRG-Developer As far as I can tell the Swift API Design Guidelines they refer to do not explicitly talk about delegate method naming. I think they are basically saying "follow Apple's lead", which I think is not a bad approach. Consistency has its benefits.
Thank you everybody for your input. I think we can close this issue as "follow Apple's lead".
I think a delegate naming guideline should come out of this even if it is along the lines of "follow Apple's lead."
https://github.com/raywenderlich/swift-style-guide/pull/181 addresses this issue
Thanks for your help on this @fabienwarniez ... if you want to add yourself to the list of contributors feel free to send a PR.
Most helpful comment
Here's my take:
(1) This guide frequently defers to Apple's guidance. For examples, see
Naming
andProtocol Naming
sections, both of which refer toFollowing Apple's API Design Guidelines
.(2) Apple frequently puts the name of the delegating (i.e.
self
) object _first_.UITableViewDataSource
andUITableViewDelegate
show _many_ examples of this:(3) Thereby, if we specify anything (I'm on the fence about whether we should or not), I think we should follow said examples. Thereby, I'd go with this signature: