> Le 14 août 2016 à 20:43, Karl via swift-evolution <swift-evolution@swift.org> > a écrit : > > >> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi folks, >> >> I see from building the latest Swift-3.0 branch that I’m a little behind the >> times and this proposal has been accepted :( >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md >> >> Is there no way we can revisit this decision? 60 emails on a mail group not >> read by the whole community >> doesn’t quite seem enough validation for such a significant change to me. Of >> those that expressed an >> opinion on the thread many were against sealing classes outside the module. >> >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html >> >> I personally feel it's a huge mistake for the following reasons: >> >> 1) it “breaks open source” reducing the reusability of third party software >> by default. >> >> 2) Contrary to arguments about the likely performance benefits of >> de-virtualisation of method dispatch it is >> likely to make Swift programs launch more slowly due to the dynamic linker >> having to slide large numbers >> of function pointers for most method calls (itself an expensive operation) >> whether a call is even made. >> >> On the first point it's an established technique in OOP to be able to >> subclass and override to adapt a class >> for a role perhaps it’s author never considered. Call this “monkey-patching” >> if you like but it is a part of being >> able to use open source libraries without having to make a fork as would be >> the case if sealed by default. >> Are we expecting developers to remember to leave their classes (and >> methods?) "open”? If they do feel >> that others shouldn’t subclass or override there was always “final". >> Distinctions about whether this is possible >> inside or outside a module seem a mute point to me. >> >> The second point is more of an engineering one. “Virtual” dispatch on Swift >> is not a significant overhead >> compared to fully dynamic dispatch on Objective-C which even then was seldom >> a problem. There is a >> cost however to de-virtualisation and resolving to a direct call to a method >> address in that the dynamic >> linker has to resolve and slide the pointer on load. This type of concern is >> a bad argument to use in >> designing a language anyway even if it is called Swift. >> >> Well, I know the boat has left on this one and I’ll likely have to live with >> it but this is the proposal I >> most disagree with on evolution this far. Programmers have morals and just >> because you shouldn’t >> do something doesn’t mean the language needs to turn that into can’t by >> default when the need arises. >> If this change does go ahead please try to get it into the next Xcode beta >> as it is a very incompatible one. >> >> Cheers, >> >> John >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > It we are happy with non-open != final, I would be in favour of some kind of > monkey-patching import attribute, similar to @testable, which allows you to > subclass non-open classes at your own risk. >
The non subclassable across module boundary is not just a compiler enforced limitation. Once you compile a module with classes that are ‘final’ in the module, the compiler may devirtualize all call sites in the module, or even inlining some calls, making subclassing unpredictable and pointless. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
