<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 1:26 PM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div class="">I really don't get why people are so obsessed with same-file extensions:</div></div></div></div></blockquote><div><br class=""></div>The same-file mentality comes from Swift 3, which introduced <font face="Menlo" color="#9a244f" class="">fileprivate</font> (which, since Swift 4, got merged into <font color="#9a244f" face="Menlo" class="">private</font> within a single file scope). With that feature, implementors don't have to choose between access protection and code locality and can get both.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">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></div></div></div></blockquote><div><br class=""></div><div><div class="">Extensions are a tool for decentralizing code. There are some critical limits on extensions that make main type definition subject to unavoidable bloating (required and designated initializers, stored properties, the deinitializer, and open methods), but everything else is a prime candidate for decentralizing. Putting as little code as possible into the type definition and semantically grouping the implementation into extensions improves readability and maintainability dramatically.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">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></div></div></div></blockquote><div><br class=""></div>Relying on comments for invariants and preconditions is a poor design decision, because there's no way of enforcing them and the whole integrity of the code is thrown at the mercy of a human's carefulness (which is a horrible fate to befall upon any code). By writing the code in such a way that makes it impossible to be misused (by way of compiler enforcement), the code becomes resilient and no amount of clumsy usage can lead to incredibly obscure bugs that would take a week of debugging to catch.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class="">[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 class=""><br class=""></div><div class="">A protocol itself is already a vehicle to group related methods,</div></div></div></div></div></blockquote><div class=""><br class=""></div>A protocol is a vehicle for generic programming and separation of abstractions.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""> 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></div></blockquote><div class=""><br class=""></div><div class="">Splitting and hiding complexity is by far the only reasonable way of dealing with huge entities. If the entity gains too much responsibility, it's probably a good idea to split it into several smaller entities. If the entity contains a large amount of accidental complexity that solely serves the purpose of enabling a select set of intended features, then it's probably a good idea to hide the accidental complexity away from users of the entity.</div><div class=""><br class=""></div><div class="">In fact, that's exactly why I always wished that protocols could get private requirements that are there solely for use in protocol extensions and are otherwise hidden from existence. I haven't talked about this in detail because I don't see a reasonable way of implementing it yet.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Also, please include the original message for reference purposes.</span></div></blockquote></div>[hopes Discourse will happen soon ;-) ]</div></div></blockquote></div><br class=""><div class="">Original Post: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038457.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038457.html</a></div><div class=""><br class=""></div></body></html>