> On Jun 28, 2016, at 9:59 AM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>> >>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> -1 for the fact that if all devs can write working code, fewer can do it >>>> in a clear structured fashion that is well designed for extensibility. >>> >>> This sounds more like an argument for having sealed classes than not. As >>> the proposal points out in the motivation, if the base class is not >>> designed with subclassing in mind then overriding methods can result in >>> unintended behavior (e.g. crashing, or other bugs). >> >> But I think the counter argument is, what if you need to fix or workaround >> unintended behavior of the class you’re trying to use? > > Typically you modify something open source - 99% of which is on GitHub. IMHO > the best way is to either fork it and perhaps submit a pull request with the > fix. > > But I understand that this is not always possible…
I agree that this is the best approach for open source dependencies. If the authors of the library disagree with you about what the public API should be then perhaps it isn’t the right dependency for your project and you should either create your own fork or find another library to use. That said, in the "final by default” thread a lot of the discussion was about working around bugs in Apple’s closed source frameworks. This line of argument isn’t really valid because changing the default in Swift won’t affect frameworks written in Objective-C and also because the default is unlikely to have a significant impact on Apple’s exposed API. Apple will be free to use `sealed` even if they need to apply it manually and is very likely to do so as soon as they start writing frameworks in Swift and `sealed` is an option. IMO the argument for introducing `sealed` and making it the default is roughly analogous to the argument for having an `internal` access level and making that the default: the author of a library should have tools to control what is and is not exposed as public API. The ability to subclass is an API contract every bit as much as anything else. The safe default is to require library authors to opt-in to all public API, thus avoiding "accidentally public” API. As was noted in previous threads, making the contract more explicit and enforcing it is viewed by many as a good thing. It prevents hackish workarounds which both facilitates framework evolution and also increases pressure on framework authors to fix their bugs in a timely manner. -Matthew > > >> >> l8r >> Sean >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
