<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="">Am 12.07.2016 um 22:54 schrieb Jean-Daniel Dupas via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div 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;" class="">If you can’t trust a developer, how could you use its library ? </div></div></blockquote><div>I guess you're getting this wrong, and maybe on purpose:</div><div>Thrusting a developer is competent and tries to do a good job is on a completely different scale than the faith that someone foresees the future and writes code without any errors.</div><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class="">Using third-party code involve some kind of trusting, as you would have to trust the developer to write reliable and efficient code, which is IMHO, far more important than knowing if the developer carefully choose what can be subclasses or not.</div></div></blockquote><div>Very true — so wouldn't it better to concentrate on topics that help developers write this code, instead of building a bureaucracy that makes coding harder?</div><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class="">And when you encounter a library where the dev choose to allow subclassing, you will have far more trust than the code was design to be subclassed.</div></div></blockquote>I have the impression that many supporters of the proposal would love to have the power to not only change a tiny part of the language, but all the people using it... luckily, this isn't true, and this would be a false feeling of security:</div><div>Even if you punish them, some developers will value the freedom of choice more than the tiny slight risk of harming someone who uses this liberty — and even the biggest bureaucrats won't get their inheritance-model right all the time...<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div 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;" class="">Some design patterns work better with subclassing than with protocol or delegation. So I’m confident than library developers will ‘open’ there classes if needed.</div></div></blockquote></div><div>Would you allow others to put you in a cage, as long as they will open it if needed?</div><div class="">I wouldn't want that, even if that cage offered some protection.</div><div class=""><br class=""></div><div class="">Tino</div></body></html>