<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Maybe some people disagree with the emphasis on the library writer POV and from a user perspective of other people's libraries they have been accustomed to how you can be trusted with enough responsibility to either fix a behaviour in the binary lib you have been given or modify the sequence of some events for user flow reasons. Let's not act like a lot of people did never benefit from method swizzling at runtime (quite often it is popular libraries we use that do that for us, but it can be an invaluable tool as many other features of the Objective-C runtime... there is a reason why UI programming and rapid prototyping are massively more enjoyable in more dynamic languages like JavaScript, ruby, and Objective-C).<br><br>Sent from my iPhone</div><div><br>On 22 Feb 2017, at 07:15, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">Le 21 févr. 2017 à 17:19, Tino Heth 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;">I’ll concede that the proposal makes a claim that might very well be disproved. I would very much like to see an actual example of a public class that **has** to be public but **shouldn’t** be open for obvious reasons. I would happily accept being shown wrong on that point.</div></div></blockquote></div>This is afaics one of the most active disputes on evolution — and you can save you a lot of grief by accepting that it is pointless:<div class="">The whole discussion isn't based on facts at all, despite many false claims that marking things as final is generally better.</div><div class="">I have asked for a single example to prove this in the past as well, so I guess no one can present such a thing to you.</div></div></div></blockquote><div><br class=""></div><div>This is bad faith. The original discussion contains many real life example. You just don’t want to admit open is useful for many library writers.</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="">It is personal preference, so arguments don't help much here.</div><div class=""><br class=""></div><div class="">Maybe it helps to know the whole story, as everything started with "final should be default", followed by a try to forbid subclassing for types from a different module by default, finally arriving at the current compromise where you have to decide wether module clients should be allowed to subclass or not.</div><div class="">Nobody ever requested that public should be the only access level, so there has been only been pressure applied from one direction — it's interesting to see some backlash now.</div><div class="">Imho people already were quite tired of discussion when public/open was accepted as a compromise...</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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>