<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">There was an order of magnitude more than 60 emails about this. In my inbox, I count 452 emails that have 0117 in the title. Discussion had already started before the proposal and I'm not counting these.<div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 14 août 2016 à 02:17:36, John Holdsworth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi folks,<br class=""><br class="">I see from building the latest Swift-3.0 branch that I’m a little behind the times and this proposal has been accepted :(<br class=""><br class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a><br class=""><br class="">Is there no way we can revisit this decision? 60 emails on a mail group not read by the whole community<br class="">doesn’t quite seem enough validation for such a significant change to me. Of those that expressed an<br class="">opinion on the thread many were against sealing classes outside the module. <br class=""><br class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022364.html<br class=""><br class="">I personally feel it's a huge mistake for the following reasons:<br class=""><br class="">1) it “breaks open source” reducing the reusability of third party software by default.<br class=""><br class="">2) Contrary to arguments about the likely performance benefits of de-virtualisation of method dispatch it is<br class="">likely to make Swift programs launch more slowly due to the dynamic linker having to slide large numbers<br class="">of function pointers for most method calls (itself an expensive operation) whether a call is even made.<br class=""><br class="">On the first point it's an established technique in OOP to be able to subclass and override to adapt a class<br class="">for a role perhaps it’s author never considered. Call this “monkey-patching” if you like but it is a part of being<br class="">able to use open source libraries without having to make a fork as would be the case if sealed by default.<br class="">Are we expecting developers to remember to leave their classes (and methods?) "open”? If they do feel<br class="">that others shouldn’t subclass or override there was always “final". Distinctions about whether this is possible<br class="">inside or outside a module seem a mute point to me.<br class=""><br class="">The second point is more of an engineering one. “Virtual” dispatch on Swift is not a significant overhead<br class="">compared to fully dynamic dispatch on Objective-C which even then was seldom a problem. There is a<br class="">cost however to de-virtualisation and resolving to a direct call to a method address in that the dynamic<br class="">linker has to resolve and slide the pointer on load. This type of concern is a bad argument to use in <br class="">designing a language anyway even if it is called Swift.<br class=""><br class="">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<br class="">most disagree with on evolution this far. Programmers have morals and just because you shouldn’t<br class="">do something doesn’t mean the language needs to turn that into can’t by default when the need arises.<br class="">If this change does go ahead please try to get it into the next Xcode beta as it is a very incompatible one.<br class=""><br class="">Cheers,<br class=""><br class="">John<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>