[swift-evolution] [Pitch] Overridable Members in Extensions

[Jordan Rose]

[Proposal: https://github.com/jrose-apple/swift-evolution/blob/overridable-members-in-extensions/proposals/nnnn-overridable-members-in-extensions.md]

> On Feb 19, 2016, at 2:23 , Marco Masser <lists at duckcode.com> wrote:
> 
>> On 2016-02-18, at 18:52, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> Sorry, I think you're misinterpreting the proposal. The note in the beginning says that for someone else's 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.
>> 
>> 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.
> 
> Sorry, when re-reading, I think my original answer wasn’t clear – either that, or I really misinterpreted the proposal!
> 
> I tried to explain why I think the proposal is a good idea in three stages:
> 
> 1. By stating how it works – or will work – when everything is in the same module:
> 
>>> 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:
>>> - Library/framework authors can freely decide to split up their classes into separate extensions without worrying about impacting clients of that library/framework.
>>> - Library/framework clients aren’t affected by the author’s choice of splitting up their classes into separate extensions.
>>> 
>>> 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.
> 
> (Note: the last sentence is not a complaint but an example of why the way it works – or will work – is a good idea).
> 
> 
> 2. By explaining how I tend to do things:
> 
>>> 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.
>>> 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. https://bugs.swift.org/browse/SR-584 <https://bugs.swift.org/browse/SR-584>). I’m looking forward to when these will be fixed for classes in the same target (as indicated by the note in the introduction), […]
> 
> 
> 3. By concluding why I think the proposal is a good idea:
> 
>>> […] but when the proposal in question gets implemented, this would also work as expected for classes in different modules.
>>> Therefore: +1 for consistency and least astonishment.
> 
> 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.
> 
> 
> I hope this clears up my original answer. Either by getting the point across better, or by proving that I misinterpreted the proposal 🙃

Yes, sorry, the proposal doesn't quite do that, because of the new safety rule:

"If an extension in module B is extending a class in module A, the extension may only override members added in module B."

…by the same reasoning in my reply to Erica: allowing this would violate the "what if two modules did this? <https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413/>" rule. You 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.)

This proposal is more about adding new overridable members in extensions than it is about overriding existing methods.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/432a0625/attachment.html>