<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=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">This is bad faith. The original discussion contains many real life example.</span></div></blockquote><div>"bad faith"? Really? If we have the same interpretation of this phrase in our dictionaries, it's only fitting here as attribute for the sentence following it.</div><div class=""><div class=""><div class="">I took a position that is extremely easy to attack, yet the only counter argument is the claim that there are many real life examples (instead of citing a single one). That's just "alternative facts", and it tells a lot about the actual power of the arguments that are used to justify forbidding subclassing.</div><div class="">Afaik, there hasn't been a single real life example by those who fought for "final by default", and it took quite a long time until someone from core came up with a scenario which illustrated a disadvantage of non-final classes in a lib — but that example had bad (worse) consequences in a final-by-default setup as well, so it wasn't convincing for me.</div></div></div><div class=""><br class=""></div><div class=""><div class="">First step in discussion should be agreeing on facts, and in this discussion, imho the most important fact is that this actually isn't about facts at all, but rather about opinion and personal preferences:</div><div class="">When someone suggests to rename the keyword "func" to "fn" or "function", it is ridiculous to argue that either choice is better, and the same is true for this topic (it just has bigger consequences).</div></div><div class="">When you actually read the original discussion, I expect you will find more false claims and questionable tactics from both parties than valuable examples, and this drags down the quality of the debate.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> You just don’t want to admit open is useful for many library writers.</span></div></blockquote></div><div class="">Of course open is extremely useful for library writers — especially for those who write libraries that are intended to be actually used…</div><div class="">Did anyone question that? (I guess the title of the thread can be a little bit irritating, but afaics, it is only the keyword that should be removed, not the feature itself).<div class=""><br class=""></div></div><div class="">As I told the author of this draft, I can only tell its opposers as well:</div><div class="">Just relax and admit that you are not fighting for the better choice, but only for the one you like better.</div><div class=""><br class=""></div><div class="">(btw, that is the case for a lot of decisions:</div><div class="">Typed throws aren't better than untyped ones, zero-based arrays aren't better than 1-based arrays, functional programming isn't better than POP or OO, composition isn't better than inheritance, structs aren't better than classes… the strongest statement you can make for some of those alternatives is that they perform better in specific situations)</div></div></body></html>