> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPhone >> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution >> <[email protected]> wrote: >> >>> On Jul 9, 2016, at 11:04 AM, Tino Heth <[email protected]> wrote: >>> >>> Second: >>> Do you really believe there will be positive impact on open-source >>> libraries? >>> My forecast is that closed by default will dramatically increase trivial >>> pull request where developers ask for unsealing so that they can do as they >>> like… >> >> I think this is a good thing. It will force a considered answer and a >> discussion about whether or not subclassing should be supported by the >> library. > > So, let's say I ask you to support subclassing in your library, and you say > no. What's to stop from just writing something like this: > class YesICan { > var foo: YouCantInheritThis > // Duplicate `YouCantInheritThis`'s public API by just passing everything > through to `foo` > } > > And overloading/extending anything else I need for `YesICan` to, functionally > speaking, inherit from `YouCantInheritThis`.
You can certainly do this, but it isn’t equivalent to subclassing for at least two reasons. First, calls within the methods of YouCantInheritThis will not call into the methods in YesICan. In other words if YouCantInheritThis has both doWork() and okIWill() methods and doWork() calls okIWill(), it will only ever call the implementation of okIWill() in YouCantInheritThis, not the implementation in YesICan. This actually gets to the heart of what one hopes to achieve through final or sealed, specifically avoiding a subclass from inadvertently changing the behavior of a superclass and assumptions the superclass is making about behavior of calls *within that superclass*. Second, you cannot pass a YesICan where you can pass a YouCantInheritThis, so if you have another library that traffics in YouCantInheritThises, your “subclass” cannot be used with it. Mark > > Yes, I know it'd all be the epitome of annoying boilerplate code, but my > point is that if someone wants to subclass something of yours, there's really > not much you can do to stop them. > > (Before anyone mentions it, yes, the same trick can be used to get around > `final` and `sealed`, but IIRC the motivations there were to enable certain > compiler optimizations, not to prohibit "unauthorized" inheritance.) > > - Dave Sweeris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
