When I look at declarations in Xcode, of Section for example, I see a main declaration and a bunch of extensions. What is the advantage of that over just having them in the main declaration?
In a related question, when you want to have a special init, but you want to retain the default implicit init, you have to put the special init in an extension. Why is this better than simply not turning off the default init if you've included one with a different signature?
For context, I see extension as being a way to modify extent types when you want local changes, or when the original code isn't available to you. This thing of extending a thing in the same file is strange.
It's a commonly used practice to break types into smaller parts, usually a main declaration and extensions to provide various protocol conformances. For the initializers, those are added in extensions if you want to keep the synthesized member-wise initializer, as you lose it if you have an init in the main type declaration. That's just a limitation of the language, one which could be lifted if we add the ability to control the member-wise initializer synthesis.
The compiler removes the implicit init when you provide an explicit init in the main declaration on the assumption that the type has invariants which must be established by the explicit init that the implicit init would permit breaking, if it existed.
However, preserving the implicit init is convenient, so the compiler provides a way to have both the implicit init and explicit inits, which is to put all explicit inits in extensions.
To me what you have just said is a contradiction. Readability is about understanding.
And I would disagree that it helps organize better than say, comments. In fact, I think it's much worse. You repeat the word extension and the name of the class n times so you can (if Apple is any indicator) add a single line.
It's usually much more than that. You can group things together by files/folder, i.e., all Codable implementations are in this file. It'd be much harder to organize large project without extension. You'd be forced to put all that is about a type in the same place, same file.
Holy Beans. Yeah, that another tradition I'm not quite a fan of: comments before the declaration. It's not horrible, but I got used to Python docstrings, which make for a very clear context. A little bit harder in the case of synthetic header files, since we are lacking a body to demarcate the end, but...
Yeah, that's why I was trying to assume there was an explanation rather than declaring it bogus off the bat. If the generated interface files can collect declarations across a code base, that'd explain the seemingly absurd division. I like the idea of Aspect Programming like abilities, so I'll not complain about it. :)
I still don't care for the way default initializers are handled. Maybe when I'm feeling bold I'll write a proposal. Prolly someone will beat me to it...
I think a lot of it comes down to style, but also, the bigger the code base, the more of these layers are necessary for it to work. Sort of like a very large organization needs layers and departments and forms, which is a lot to wade through and sometimes not helpful for getting simple things done. Unfortunately, it does have its place. In particular, the dividing of the code by protocols lets you quickly know where to find the protocol conformance and compare across types. It also helps isolate code when multiple people need to work on or review something.
They seem trendy in Swift despite the fact they existed also in Objective-C.
Swift Extensions are often times used in 3 ways (there are more):
Retroactive Modeling
Protocol Extensions
For organization purposes, where grouping a set of methods together within the same file that declared that class. For example, grouping private methods in an extension, or an extension to implement each protocol that the class implements.
The use of swift extensions for with regards to point 3 above is very trendy right now and I feel strongly that it is incorrect and has drawbacks. A simple // MARK: achieves the “code organization” intention of using extensions.
Reasons to not use extensions for organizing code within the same file:
Unlike MARKs, they do not show up in the source editor summary dropdown in Xcode. (Screenshot: Dropbox - File Deleted)
Must scroll through the file to find all protocol conformances
Extensions obviously can’t override methods, hence this limits how these groups are composed
Can’t add properties to extensions, so grouping is somewhat false and not always fully contained as they may suggest
Take more space than MARKs and not as concise
Lead to longer compile times (I am finding a source for this)
Myth: Extensions don’t fully force protocol conformance to be in the scope of that extension
Myth: They do not give ability to implement protocol privately
Objective-c has categories offer ability to be named yet this pattern isn’t trendy there, suddenly its trendy in Swift.
- but you better be careful with such opinions ;-)