> On Jun 28, 2016, at 10:17 AM, Mark Lacey via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 28, 2016, at 7:55 AM, Sean Heber <s...@fifthace.com> 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? > > Sure, I understand that, and I don’t mean to trivialize that concern. I’m > just pointing out that “code…that is [not] well designed for extensibility”, > might not work very well if you start using extension points that weren’t > well thought through. > > If you are designing for extensibility you’ll be carefully thinking about > what should and should not be final both within and outside of your module. > Not doing so can result in bugs. This proposal introduces the ability to > allow extension within the module but restrict it outside the module, and > defaults to not allowing extension beyond the module. > > You can argue both ways which default would be better, and I suspect people > who mostly write libraries might opt for sealed-by-default, and people who > mostly consume libraries might opt for open-by-default. My point is that > open-by-default isn’t “better” because it allows you to potentially work > around a problem in a base class, because by working around that problem by > overriding a method that wasn’t designed to be overridden you don’t know how > many other new problems you might be introducing (now or in the future if the > implementation of the base class changes).
I think a good argument for sealed by default is that if we introduce `sealed` responsible library authors will already be marking all classes not intended for external subclassing as either `sealed` or `final` anyway. The intended (and hopefully actual) public API will be identical regardless of the default. Making it the default avoids a lot of boilerplate keywords and makes ensure the API contract is stated more explicitly. The only case where the default should make a difference is when a library is written without consideration of subclasses. As you point out, in that case it is a really bad idea to attempt to work around a bug with a subclass. > > Mark > > _______________________________________________ > 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
