> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution > <[email protected]> wrote: > >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >> <[email protected]> wrote: >> >>> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >>> <[email protected]> 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... > > l8r > Sean > > _______________________________________________ > 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
