<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 class="">[Proposal: <a href="https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-" class="">https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-</a>members-in-extensions.md]</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 19, 2016, at 2:23 , Marco Masser <<a href="mailto:lists@duckcode.com" class="">lists@duckcode.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-18, at 18:52, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Sorry, I think you're misinterpreting the proposal. The note in the beginning says that for <i class="">someone else's</i> library, you don't need to care whether something came from a class or an extension. That doesn't work today, but it's already a direction we're planning to go.</div><div class=""><br class=""></div><div class="">This proposal covers the case where the extension is for a class in another module. In this case, things are trickier, because any number of people could be extending classes they don't own. That's why the proposal has the new (bolded) safety rule.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">Sorry, when re-reading, I think my original answer wasn’t clear – either that, or I really misinterpreted the proposal!</div><div class=""><br class=""></div><div class="">I tried to explain why I think the proposal is a good idea in three stages:</div><div class=""><br class=""></div><div class="">1. By stating how it works – or will work – when everything is in the same module:</div><div class=""><br class=""></div></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=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The introduction states in the note that in the same module, this is planned to work anyways, so if I understand correctly, there are two groups of people who are impacted by the same thing:</div><div class="">- Library/framework authors can freely decide to split up their classes into separate extensions without worrying about impacting clients of that library/framework.</div><div class="">- Library/framework clients aren’t affected by the author’s choice of splitting up their classes into separate extensions.</div><div class=""><br class=""></div><div class="">It would really be unfortunate if I couldn’t override a specific method of NSButton just because the App Kit team implemented that method in an extension instead of the class proper.</div></div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div><div class="">(Note: the last sentence is not a complaint but an example of why the way it works – or will work – is a good idea).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">2. By explaining how I tend to do things:</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=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I tend to split up my classes in a couple of extensions that each group members that somehow belong together, e.g. a separate extension for all @IBActions, one extension implementing conformance to a protocol, one private extension with methods dealing with X, etc.</div><div class="">Right now, I always tend to write all methods that override something into the class itself, not an extension because I know there are weird issues you can run into (e.g. <a href="https://bugs.swift.org/browse/SR-584" class="">https://bugs.swift.org/browse/SR-584</a>). I’m looking forward to when these will be fixed for classes in the same target (as indicated by the note in the introduction), […]</div></div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">3. By concluding why I think the proposal is a good idea:</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=""><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="">[…] but when the proposal in question gets implemented, this would also work as expected for classes in different modules.</div><div class="">Therefore: +1 for consistency and least astonishment.</div></div></div></blockquote></div></div></div></blockquote><br class=""></div><div class="">What I mean by that last point is that by implementing this proposal, my habit of doing things (splitting up a class into a couple of extensions) would not only work when everything is in the same module, but also when the class and its subclasses are split across different modules. If I understand correctly, the proposal takes overriding members out of the decision making process for splitting classes into extensions, i.e. whether those extensions can override something or not depending on whether the class or superclass is defined in the same module or not. I would therefore say that it improves consistency in that it doesn’t matter in which module I write an overriding member in an extension: it works the same everywhere.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I hope this clears up my original answer. Either by getting the point across better, or by proving that I misinterpreted the proposal 🙃</div></div></div></blockquote><br class=""></div><div>Yes, sorry, the proposal doesn't quite do that, because of the new safety rule:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div class="">"If an extension in module B is extending a class in module A, the extension may only override members added in module B."</div></div></blockquote><div><br class=""></div><div>…by the same reasoning in my reply to Erica: allowing this would violate the "<a href="https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413/" class="">what if two modules did this?</a>" rule. <i class="">You</i> know that you've broken up your plain old app into multiple modules, and that no one else is going to extend the classes you defined there, but the compiler doesn't. (And moreover, it's not as easy to add overrides after the fact with Swift as it is in Objective-C.)</div><div><br class=""></div><div>This proposal is more about adding new overridable members in extensions than it is about overriding existing methods.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>