<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="">On 11 Jul 2016, at 03:49, let var go via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Leonardo's example makes the case for why Swift should adopt a 'sealed' keyword that can be used to make public classes non-subclassable outside the module where they are defined, but not for why this should be the default.<div class=""><br class=""></div><div class="">Others have made these points before, but these are the two biggest reasons I can see against making public classes non-subclassable by default:</div><div class=""><br class=""></div><div class="">1. It is the opposite of nearly every other OOP language's behavior and the opposite of what anyone will expect who is coming to Swift after doing any OOP programming anywhere else. While I believe that Swift should be free to buck the trends of other languages where there are significant advantages, changing something this fundamental will introduce a new learning curve for even experienced programmers. The advantages better be significant, otherwise you are introducing a frustrating quirk into the language without any great benefit in exchange. But the advantages of default non-subclassability are marginal at best. Whatever advantage there is can be achieved by making it opt-in using a 'sealed' keywrod, instead of by making it the default.</div></div></div></blockquote><div><br class=""></div><div>As stated previously in this thread, modern languages like Kotlin do have this behaviour and base themselves on what is recommended good design in Java. So we this behaviour is not necessarily new or orthogonal to nearly every other OOP language. Secondly, I don’t agree that the advantage of default non-subclassability is marginal at best. It will have very real repercussions on the robustness and documentation of third-party libraries.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">2. The motivation seems to be that it will force better API design. On average, I can't believe that it will. Assume that there are two kinds of developers: Those that make careful decisions about their API design and those that don't. The ones that make careful decisions about their API design will continue to do so - I don't see any significant improvement to their code by making non-subclassability the default.</div></div></div></blockquote><div><br class=""></div><div>The improvement is that extension points will be clearly and explicitly marked, instead of having to rely only on documentation (which can be lacking, even from developers that make careful decisions about their API design).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">The developers who don't make careful design decisions will just go with the default - in this case they will just leave the default in place, and their public classes will not be subclassable. That doesn't improve anything, it just makes sloppy, poorly written code harder to fix in the off-chance that you are stuck working with it. In other words, quality will not improve, but productivity will suffer, because it will be harder to develop workarounds for the problems that will inevitably appear in even the best-designed APIs.</div></div></div></blockquote><div><br class=""></div><div>Here, I also disagree. Imagine we are talking about an open-source library on GitHub. People will complain about the lack of sub-classability through issues and pull-requests. This will hopefully be enough to get discussions going on what is wrong with the API to warrant subclassing and exactly what the subclassing extension points should be. This discussion will happen around many libraries and will help educate people to think carefully about subclassing.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">3. It is a bad interpretation of the stated goal that Swift should help developers produce "safe code." Some folks seem to believe that this means that the language should protect people from themselves. If I am using your API in my code and I screw it up by subclassing something that I shouldn't have, that is somehow a language defect. It is not a language defect - it is me being an idiot.</div></div></div></blockquote><div><br class=""></div><div>This argument could very well be transposed to defend C's memory-management and does not stand for me. A language should always strive to protect developers from their own mistakes. If that was not the case, languages would never have introduced garbage collection, ARC, optionals, etc...</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Don't spend a lot of time trying to make a language idiot-proof - idiots are geniuses and you will never outsmart them. Personally, when I read that Swift helps produce "safe code", what that means primarily is that it has a type system that helps reveal the vast majority of bugs that would otherwise go unnoticed until runtime. In other words, safety is related to discovering hidden flaws in the program. (Type safety isn't the only feature that helps with this, but it is perhaps the main one.) But this whole issue of default non-subclassability doesn't fall into that category of "safety" at all. It doesn't help a programmer produce safer code. The same hidden flaws will persist whether non-subclassability is the default or not. The difference is that those same hidden flaws will be more difficult to deal with after the fact.</div></div></div></blockquote><div><br class=""></div><div>How can it not help programmers produce safer code? By not subclassing a brittle class, it does protect them from internal modifications in that superclass.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">To sum it up, +1 for introducing a 'sealed' keyword, but -1 for making it the default behavior for public classes.</div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jul 10, 2016 at 12:18 PM Leonardo Pessoa 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"><div class=""><div class=""><div style="font-family:Calibri,sans-serif;font-size:11pt" class="">Should I assume then you want so much this proposal to be dropped you didn't even mind to look for the example so you wouldn't have to admit this proposal is needed? Fine, here is the whole of that example.<br class=""><br class="">I'm currently working on an app which will have object representations of Files and Folders (both come from a common class called Entry). You as a developer for this system will be entitled to extend from File and Entry freely but you can only work with Folders and its subclasses (specialised folders) but to this system it is important you don't subclass any type of folder. Without this proposal I would have to create workarounds to prevent you from doing that while still allowing me to subclass while playing a lot of finals everywhere. And so far I would have to allow you to subclass Folder itself (at least) but you would complain (and possibly file a bug report to me) because it would not be working properly because your classes would not benefit from the workaround. In this case, if I could subclass internally but prevent you from doing it, you could complain I'm not allowing you to do whatever you want but you wouldn't complain my code doesn't work properly (it does, you just won't know it).<br class=""><br class="">There may be several more examples but this is one I'm facing right now, so I can assure you it is a true example. IMO libraries are to be written with intention in mind and I don't think it is right to use a library written to compose a PDF file to send an email (even if you're sending the PDF file attached, the right way to do it is by composition not subclassing).<br class=""><br class="">Additionally, someone mentioned and I went in to check about a recommendation for Java to intentionally document and enable classes to be subclasses explicitly otherwise forbid it at all and that recommendation seems to come from Oracle itself. I believe Oracle would do it to Java if it had great interest in it without consulting anyone's opinion.<br class=""><br class="">About the addition to the proposal to enable force unsealing, I'm completely opposed as it is just like not having any of this protection at all (why putting a lock on the door to your house if the key is under the mat?)<br class=""><br class="">Swift doesn't have to follow on the footsteps of any language but what is best for the intention the language was created for. If sealed by default goes in that direction, then we should have it not looking back. The same goes if we decide this is not taking the language in its intended direction. If I'm not wrong at least one member of the core team already mentioned in this thread this is completely aligned with the intention of the language, so I think we should give it a go and stop trying to have/keep control of everything we touch.<br class=""><br class="">L</div></div><div dir="ltr" class=""><hr class=""><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold" class="">From: </span><span style="font-family:Calibri,sans-serif;font-size:11pt" class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">Tino Heth via swift-evolution</a></span><br class=""><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold" class="">Sent: </span><span style="font-family:Calibri,sans-serif;font-size:11pt" class="">10/07/2016 01:55 PM</span><br class=""><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold" class="">To: </span><span style="font-family:Calibri,sans-serif;font-size:11pt" class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution</a></span><br class=""><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold" class="">Cc: </span><span style="font-family:Calibri,sans-serif;font-size:11pt" class=""><a href="mailto:mailing@xenonium.com" target="_blank" class="">Jean-Daniel Dupas</a></span><br class=""><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold" class="">Subject: </span><span style="font-family:Calibri,sans-serif;font-size:11pt" class="">Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly</span><br class=""><br class=""></div></div><div class="">Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something.<br class="">I got a single reply — which did not contain an example, but just the claim that there is one…<br class="">Imho that alone should be enough to cancel the whole thing, because even if there are cases which cannot be repelled with the simple advice "just don't subclass", this would only be a basis to start talking about the actual pros and cons.<br class=""><br class="">So for me, the promised benefits are less likely than the existence of Bigfoot:<br class="">I guess there are at least several hundred people who swore they have seen him, and there are even some blurry photos ;-)<br class=""><br class="">Of course, it is impossible to come up with an unquestionable argument for the change — and it's also impossible to prove the opposite, because the whole debate makes as much sense as arguing wether raisins are tasteful or terrible; it's nothing but personal preference, and the only thing we can hope for is that the bias of those who will decide this proposal isn't at odds with the needs of the majority.<br class=""><br class="">If we can agree that it is not about facts, but about opinion, there are still fundamental arguments against SE-0117:<br class="">Those who have issues with subclassing can just resign from it (as users of a library), and they can annotate their classes to dictate their usage (as an author) — but if you think subclassing is still a good tool, you can't do anything with a sealed class.<br class="">Additionally, please note that those who ask for stricter rules and more regulation have many reasons to be happy with the status quo:<br class="">You can subclass neither structs nor enums, and by default, you can't inherit from a framework-class as well, because it is internal — and yet they yell for more.<br class=""><br class="">Swift claims to be opinionated, not to aim for compromise — but if plain old OO isn't compatible with the ideals of the language, it would be more honest to just completely remove inheritance instead of slowly crippling it's possibilities.<br class=""><br class="">- Tino<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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>_______________________________________________<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></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>