[swift-evolution] Module conflicts (was: Overridable Members in Extensions)

[Jordan Rose]

> On Feb 18, 2016, at 11:10, Erica Sadun <erica at ericasadun.com> wrote:
> 
> 
>> On Feb 18, 2016, at 11:38 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> [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 <mailto: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.)
>> 
>> Jordan
>> 
> 
> Going completely off into left field: Is there an ongoing discussion of module conflicts? Where there are two modules named, for example, SwiftString, and module implementation overlaps, and strategies for partial imports? Sort of "What if importing two modules does this?"

Below the module level (i.e. "assuming that module names are unique"), we've been going by the idea that nothing will conflict at the binary/symbol/runtime level as long as you don't touch Objective-C. That doesn't always reflect up happily at the source level (it's not too difficult to contrive unresolvable ambiguities with extension members), but the attitude there has been that we'll be able to dig ourselves out with language extensions that let you specify modules in various places explicitly.

When ObjC enters the picture, members have to be careful of selector conflicts. That's not wonderful, but it's no worse than things were in Objective-C itself, and making 'private' things @nonobjc by default may help with some of the inadvertant conflicts people have hit in the past. Types will only conflict if explicitly renamed (classes) or marked @objc (enums).

But when modules themselves conflict, we're in trouble. Module name uniqueness is a pretty strong part of guaranteeing the uniqueness of everything else. You can't just rename them if there's a conflict, because they show up in, say, NSCoding archives. We've mostly just pushed the ObjC prefix problem up a level.

Max from the Package Manager team may have more thoughts here; over on swift-build-dev this is a very practical problem.

Jordan

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