<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 2, 2017 at 12:26 PM, Tino Heth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">That would work as well, but it has the downside of forcing a potentially huge number of methods to be implemented in a single place, reducing the readability as opposed to packing them into semantically related groups in the form of extensions.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote></span><div>I really don't get why people are so obsessed with same-file extensions:<div>They are recommended in style guides, influencers blog about them, and they motivated a ridiculous complex change in the access rights system. Yet I haven't seen any evidence that they offer real benefit.</div><div>Extensions are great for adding useful helpers to existing types, and still allow you to selectively expose details of your own classes — but most people seem to ignore those options and focus on something can be done better with plain old comments.</div><div>[sorry for the rant — but I think a critical look at extensions is long overdue: I rarely see someone questioning their role, so basically, we are making important decisions based on pure superstition]</div><div><br></div><div>A protocol itself is already a vehicle to group related methods, and if you have a huge entity, it doesn't get better just because you split it and hide its complexity.</div></div></div></div></blockquote></div><div class="gmail_extra"><br></div>In my organization we use same file extensions to group methods by visibility (and also by protocol conformance), so instead of:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="monospace, monospace">public class MyClass {</font></div><div class="gmail_extra"><font face="monospace, monospace"> public func method1() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> public func method2() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> public func method3() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> public func method4() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> public func method5() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> private func method6() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> </font><span style="font-family:monospace,monospace">private</span><font face="monospace, monospace"> func method7() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> </font><span style="font-family:monospace,monospace">private</span><span style="font-family:monospace,monospace"> func method8() {}</span></div><div class="gmail_extra"><font face="monospace, monospace"> </font><span style="font-family:monospace,monospace">private</span><font face="monospace, monospace"> func method9() {}</font></div><div class="gmail_extra"><span style="font-family:monospace,monospace">}</span><br></div><div class="gmail_extra"><br clear="all"><div>We write:</div><div><div class="gmail_extra"><font face="monospace, monospace"><br class="gmail-Apple-interchange-newline">public class MyClass {</font></div><div class="gmail_extra"><font face="monospace, monospace">}</font></div><div class="gmail_extra"><font face="monospace, monospace"><br></font></div><div class="gmail_extra"><font face="monospace, monospace">public extension </font><span style="font-family:monospace,monospace">MyClass</span><span style="font-family:monospace,monospace"> {</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace"> </span><span style="font-family:monospace,monospace"> </span><font face="monospace, monospace">func method1() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> func method2() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> func method3() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> func method4() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> func method5() {}</font></div><div class="gmail_extra"><span style="font-family:monospace,monospace">}</span><br></div></div><div><div class="gmail_extra"><font face="monospace, monospace"><br class="gmail-Apple-interchange-newline">private extension </font><span style="font-family:monospace,monospace">MyClass</span><span style="font-family:monospace,monospace"> {</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace"> func method6() {}</span><br></div><div class="gmail_extra"><font face="monospace, monospace"> </font><font face="monospace, monospace">func method7() {}</font></div><div class="gmail_extra"><font face="monospace, monospace"> </font><span style="font-family:monospace,monospace">func method8() {}</span></div><div class="gmail_extra"><font face="monospace, monospace"> </font><font face="monospace, monospace">func method9() {}</font></div><div class="gmail_extra"><span style="font-family:monospace,monospace">}<br></span></div></div><div><br></div><div>The main reason is not having to repeat the visibility modifier, although this brings several other advantages and makes our code style more consistent and easier to follow:</div><div><br></div><div>- It forces us to put the private methods at the end of the file, and that's good because they are implementation details and thus not the first thing a reader should see. You could do this with comments, but the syntactic separation seems stronger.</div><div>- It makes trivial switching the visibility of the "public methods". For example we extracted some frameworks from our app and thanks to this organization it was trivial to change every internal definition to public ones.</div><div class="gmail_extra"><div><div>- It also works with other modifiers like @objc.</div></div><div><br></div></div>-- </div><div class="gmail_extra">Víctor Pimentel<div class="gmail-m_-2608660224022982194gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div style="font-size:12.8px"></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>