<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 9 juil. 2016 à 18:22, L. Mihalkovic 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><div class="">Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div class=""><br class="">On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 9, 2016, at 8:39 AM, Andre <<a href="mailto:pyunpyun@me.com" class="">pyunpyun@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Personally, Im not against sealed by default, but I think there are cases where closed source libraries have certain cases where workarounds are necessary, and just sealing by default will prevent those cases. <div class=""><br class=""></div><div class="">One could say, "well just use an open source one, or change vendors" but its not that easy in The Real World™ where we get certain SDKs shoved down our throats by the suits… and while that may be a separate issue to the one at hand, its still a problem that won’t resolve itself by simply locking down things…</div><div class=""><br class=""></div><div class="">In my own case, Ive fought with NSBrowser / NSTreeController in the past and the only way to resolve things was to subclass (and no, waiting 1 or 2 years for a fix is not acceptable if you already have a product in the wild).</div><div class=""><br class=""></div><div class="">So I am reticent to support this proposal without an escape hatch for those cases…</div></div></div></blockquote><div class=""><br class=""></div><div class="">Are you concerned about closed-source vendor frameworks beyond Apple’s? Some things to consider:</div><div class=""><br class=""></div><div class="">1. This proposal should not impact any existing libraries - nobody should be shipping closed-source binary libraries written in Swift yet.</div><div class=""><br class=""></div><div class="">2. Apple’s frameworks will probably remain in Objective-C for some time to come. If / when they are replaced with Swift frameworks the default will have little (if any) impact on the public API contract. It is reasonable to expect that Apple will review the public contracts carefully and add any annotations necessary to achieve the desired semantics.</div><div class=""><br class=""></div><div class="">3. In the future, if you depend on any 3rd party closed-source libraries written in Swift you will be able to ship an update to your app that contains an updated / fixed version of the library independent of the user upgrading their OS.</div><div class=""><br class=""></div><div class="">This leaves the scenario of a case where you depend on a 3rd party, closed-source library written in Swift and where you cannot get (or use) a fix from the vendor for some reason. This is a legitimate concern, but IMO it is not large enough to outweigh all of the advantages of making sealed the default. </div><div class=""><br class=""></div><div class="">There is no doubt that adopting sealed by default will place some pressure on the Swift ecosystem. As others have noted, this pressure already exists in the form of value types, protocol-oriented designs, etc - the current proposal is a relatively modest increase in that pressure. I believe the pressure will have a very positive impact over time (the eventual outcome remains to be seen of course). </div><div class=""><br class=""></div><div class="">Swift library vendors will need to choose between opening their source, providing responsive support and bug fixes, explicitly providing the escape hatch you mention (by designing with open types) or getting a bad reputation among users.</div></div></div></blockquote><div class=""><br class=""></div><div class="">There are IMO no advantages to sealing by default. If there were, I cannot imagine how they can have so consistently eluded the designers and maintainers of so many great OOD languages in the last 30 years. Does it mean it is just a matter of time for the core team to take it the c++ standardization committee to make sure C++ gets enhanced the same way?</div><br class=""></div></div></blockquote><div><br class=""></div><div>You can’t compare Swift to C++ here. C++ uses « final » method and static dispatch by default, so subclassing does not imply the same fragility than with a fully dynamic language.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">-Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Andre<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">2016/07/09 22:11、Shawn Erickson <<a href="mailto:shawnce@gmail.com" class="">shawnce@gmail.com</a>> のメール：</div><br class="Apple-interchange-newline"><div class="">What I don't get in the arguments against this capability is the fact that many constructs in Swift can't be subclassed. Are we going to prevent library developers from presenting those in the public API? Your ability to subclass things when not supported by the library developer is already going to be greatly reduced. Additionally you are going to miss potentially helpful optimization in side the model if the library developer can't prevent extras subclassing.<br class=""><br class="">It seems perfectly reasonable to allow a lot of freedoms for a library developer when designing their code on their side of the library API and not force them to expose unwanted API just because of internal design desires. <br class=""><br class="">(I have myself have already struggled with having to leak what I consider internal details outside of modules we have developed internally, likely need to get around to outlining the additional issues I see)<br class=""><br class="">In the end if the library isn't good and you don't like the API find one that works the way you need (or make one). I expect a fairly rich environment of libraries that will sort itself out over time.<br class=""><br class="">-Shawn<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
> However, you *do not* want any new subclasses added as you know that is not likely to end well.<br class="">
Im curious, what kind of real-world scenario would "not end well" cover?<br class="">
<br class="">
I’m genuinely curious, since Im still on the fence about this, but am willing to be convinced… if sealed by default brings more positives than negatives…<br class="">
<br class="">
Thanks in advance.<br class="">
<br class="">
Andre<br class="">
<br class="">
<br class="">
> 2016/07/09 21:36、Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> のメール：<br class="">
><br class="">
><br class="">
><br class="">
> Sent from my iPad<br class="">
><br class="">
>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>><br class="">
>> Sent from my iPhone<br class="">
>><br class="">
>>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>>><br class="">
>>> Even in Java, it is a bad idea to leave classes subclassable; but having to remember to add final is a chore.<br class="">
>><br class="">
>> I still think it is worth doing that chore. The fact of the matter is that Java did not and is not enforcing that default and how many widely used production languages you know that do enforce this by default instead of asking library authors to do this bit of work?<br class="">
><br class="">
> People keep talking about just adding final. This *is not* an alternative. We are not talking about preventing subclasses by default (i.e. final by default).<br class="">
><br class="">
> We are talking about preventing subclasses *in other modules* by default (i.e. sealed by default). The alternative would be to introduce a sealed keyword (or similar).<br class="">
><br class="">
> There are times when you *need* to use subclasses inside your module. Some or all of them may not even be directly visible externally (class clusters). However, you *do not* want any new subclasses added as you know that is not likely to end well. This is why having sealed, not just final, is important.<br class="">
><br class="">
> By choosing sealed as a default rather than final, we are keeping the "subclassable by default" status *within* modules. This facilitates experimentation and eliminates the need for application level code to opt-in to subclassing while still making external API contracts explicit and therefore hopefully more robust. It is the default most in-line with the values and goals of Swift.<br class="">
><br class="">
> 'final' and 'sealed' are two very different things. Let's please keep this focused on what is actually being proposed.<br class="">
><br class="">
>><br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>