> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPhone >>>> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> 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. > What if created a protocol
YouCantInheritThisCloneProtocol{ // everything in sealed class } Then you extended the sealed class to conform to the clone protocol. Changed the other API that you have source to take a Clone Protocol derived object. This is getting out of hand :) but I think we need a middle ground somewhere. > 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution