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

Jordan Rose jordan_rose at apple.com
Thu Feb 18 12:38:38 CST 2016

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

> On Feb 18, 2016, at 10:29, Erica Sadun <erica at ericasadun.com> wrote:
>>> I'm presuming that this will not allow you to swap out one implementation for another? If not then it may be necessary to be able to call or refer to the original version of the method.
>> This is only for subclass-overriding, not ObjC-category-style method replacement.
>> Jordan
> I hate to go all Abrahams on you, but do you have any use-cases where you're delivered a subclass and a superclass in a module, where there's no subclass implementation, and you want to add one that's an override via an extension rather than just sub-subclassing?

That violates the "what if two modules did this? <https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413/>" rule. Either you own the class and you can do whatever you want to it (accepted work), or you own the method and you can override it all you want (this proposal). Anything else is unsafe (and not future-proof, if the library is part of the OS), and therefore at the very least outside the scope of this proposal.

(It's also harder to implement with a vtable instead of an ObjC-style method table, because the original class has all of its overrides and non-overrides listed in the constant section of its binary.)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160218/6328cb94/attachment.html>

More information about the swift-evolution mailing list