[swift-evolution] Idea: Named extensions

[Brandon Knope]

Because to me this seems too indirect and not explicit enough.

I think doing it explicitly:
• Makes your intent much clearer
• Forces you to think about not throwing everything into one big extension (i.e. somewhat more binding than a comment that can easily be looked over)
• Shows that it’s a first class feature of the language, encouraging everyone to use it. Makes it easier to see in tutorials and code samples as it reads more natural than // MARK:
• Does not feel hacky with a comment (and comments are easy to forget to update, making them possibly outdated)
• Looks better than having to use comments (imo)

It is reminiscent of named categories in Objective-C where I found the names to be quite self documenting and clearer.

To me it just feels like a natural extension…onto extensions.

In the end, there is nothing with wrong using comments, but it feels a little more archaic to me. 

For a little contrived example:

In the swift guide, there is an example like this:

extension Double {
    var km: Double { return self * 1_000.0 }
    var m: Double { return self }
    var cm: Double { return self / 100.0 }
    var mm: Double { return self / 1_000.0 }
    var ft: Double { return self / 3.28084 }
}

• It is clear what the intent is here: to provide methods to convert a double into other units
• Why not make this intent explicit? Otherwise it is too easy to add unrelated methods:

extension Double {
    var km: Double { return self * 1_000.0 }
    var m: Double { return self }
    var cm: Double { return self / 100.0 }
    var mm: Double { return self / 1_000.0 }
    var ft: Double { return self / 3.28084 }

	    var squared: Double { return self * self } //This computed property is unlike the others, introducing some bloat to this extension
}



Something like this is more “explicit”

 named Unit Conversion extension Double {
    var km: Double { return self * 1_000.0 }
    var m: Double { return self }
    var cm: Double { return self / 100.0 }
    var mm: Double { return self / 1_000.0 }
    var ft: Double { return self / 3.28084 }

	  //var squared: Double { return self * self } It is not clear that this method does not fit with the others and should be moved
}

There is somewhat of a contract here where everything in this extension is a kind of conversion. Anyone could still add whatever they want to this extension because this is really just a form of documentation and it has no idea whether what you are adding fits with the name, but I find it to be a little more binding and requires the programmer to ask themselves if their addition fits with the rest of the extension.

The obvious question again is: Why not just use a comment to document it? My answer to this is: I don’t think most use comments to signify their intent of the extension. They either do not know it exists or do not find it worthwhile. I think making it explicit to the language gives people incentive to use it. It would be included in more code samples because it is a natural part of the extension and not “just another comment” to skim by, meaning more people would know it exists and use it more.

Also, no // MARK: Bar syntax needs to be remembered. MARK: is also less pretty and harder to type

More formatting options:

named Unit Conversion 
extension Double {
}

extension Double, named Unit Conversion { //avoids requiring “ "
} 

At the end of the day, how many developers know and remember to use // MARK:? I think this feature with code completion would promote much wider adoption.

Brandon

> On May 16, 2016, at 1:33 PM, Michael Peternell <michael.peternell at gmx.at> wrote:
> 
> Why not just use a (documentation) comment?
> 
> /// The Lifecycle extension:
> extension ViewController {
> ...
> 
> -Michael
> 
>> Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution <swift-evolution at swift.org>:
>> 
>> I like to separate methods into their own logical extensions so similar methods are grouped together. I do this mostly with Cocoa Touch where I like all view life cycle methods to be in the same extension:
>> 
>> extension ViewController {
>>    override func viewDidLoad() {
>>    }
>> 
>>    override func viewWillAppear(animated: Bool) {
>>    }
>> 
>>    override func viewDidDisappear(animated: Bool) {
>>    }
>> }
>> 
>> You can document this somewhat by adding a MARK comment:
>> 
>> // MARK: Lifecylce
>> extension ViewController {
>>    override func viewDidLoad() {
>>    }
>> 
>>    override func viewWillAppear(animated: Bool) {
>>    }
>> 
>>    override func viewDidDisappear(animated: Bool) {
>>    }
>> }
>> 
>> What if we made this more self-documenting by elevating this to a language feature?
>> 
>> extension ViewController named Lifecycle {
>>    override func viewDidLoad() {
>>    }
>> 
>>    override func viewWillAppear(animated: Bool) {
>>    }
>> 
>>    override func viewDidDisappear(animated: Bool) {
>>    }
>> }
>> 
>> Other ways:
>> extension named Lifecycle ViewController { }
>> extension named “View Lifecycle" ViewController { }
>> extension ViewController named “Multi word description” { }
>> 
>> 
>> For now, this is purely a documenting feature (i.e. Can’t refer to the extension name dynamically or statically in actual code). I think it plays much more naturally with Swift than requiring this to be in the comments and would work across all IDEs and make it easier for people to find a specific extension as well as making their code more self documenting.
>> 
>> Any thoughts?
>> 
>> Thanks,
>> Brandon
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

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