> On Jun 28, 2016, at 8:09 AM, Javier Soto via swift-evolution > <[email protected]> wrote: > IMO the issue with the argument that we wouldn't be able to "monkey patch" > things on sealed classes is that that is already the nature of Swift. The > designer of an API can choose to use structs instead of classes, and then > there's already no way to "subclass". Moreover, "final" already exists, and > whether sealed is introduced or not, and whether it becomes the default or > not, API designers are already free to use final in all classes they do not > intend to be subclassed, so I think that would be an argument against final > existing in the first place, and that ship has already sailed. > > As for whether sealed would allow for optimizations: my hunch is that it > would. However, as I write this I noticed a flaw with my proposal: I said > that sealed classes would be exported as final. This is only half-true. They > would in that they can't be subclassed outside the module, but there could be > subclasses in the same module! That means if the parent were to be treated as > final, code outside the module would incorrectly devirtualize non-final > methods.
Also, note that: - we're clearly going to have to import ObjC classes as subclassable by default, and in fact there's currently no way to explicitly declare an ObjC class to be final; - many classes in ObjC are actually intended to be subclassed (although not every method is intended to be overridden), and those tend to be the classes that users most want to patch; - methods in ObjC can just be directly monkey-patched without subclassing, even if we're not necessarily happy about you doing it; and - even if we re-implemented a bunch of frameworks in Swift, we'd still have to maintain compatibility with some amount of this stuff. So I don't think that sealed-by-default would have any significant impact on the ability to patch Apple code as a third party. For code that isn't deployed in an OS that won't be updated, the obviously better solution is to fix the library, either yourself or, if it's closed-source, through your normal vendor support process. John. > On Tue, Jun 28, 2016 at 7:59 AM Charlie Monroe via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >>> > >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution > >>> <[email protected] <mailto:[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] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > -- > Javier Soto > _______________________________________________ > 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
