<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 11.07.2016 um 03:45 schrieb Rod Brown <<a href="mailto:rodney.brown6@icloud.com" class="">rodney.brown6@icloud.com</a>>:</div><br class="Apple-interchange-newline"><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;">That said, I actually think you have a good point however that “sealed” should be able to be overridden, either in a patch capacity or an “unsafe” capacity. Should this become final at a later point, you have acknowledged you know this will be unsafe and are willing to take this risk to get the job done. This is opt-in risk.</div><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;"><br class=""></div><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;">Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just have a keyword for “Open” as an access level, and if you subclass or override things that are not “open” from other modules, you must mark unsafe.</div><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;"><br class=""></div><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 think this is a decent compromise: We allow potential to patch, but discourage without acknowledgement of the risk. Allow Final and Open to be declarative.</div></div></blockquote></div>Finally: Someone from the other party who not only speaks about compromise, but also shares a compatible way of thinking :-)<div class="">All those strict rules are a pointless attempt to trade freedom for security, and are purely cosmetic in most cases: In the context of open source, they are a blunt sword, whose only power is to annoy users.</div><div class="">Instead of trying to avoid all possible problems users of your library may run into, it's better to treat them as adults who know what they are doing — and make sure that the actually know what they are doing.</div><div class=""><br class=""></div><div class="">The defaults should match reality, and that is neither "overriding is trouble" nor "it's safe to subclass"; it is "I haven't thought about overriding yet".</div><div class=""><div class=""><div class="">There is even a natural choice for the syntax to acknowledge that you are aware of doing something that might be dangerous: Simply add an exclamation mark to override.</div></div><div class=""><br class=""></div></div><div class="">Tino</div><div class=""><br class=""></div></body></html>