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 <[email protected]>
> 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
>> <[email protected]>:
>>
>> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
