<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 18 Jul 2016, at 18:31, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br class="">
</span>At the same time, your solution results in a lot of unnecessary boilerplate.</blockquote><div class=""> </div><div class="">It's an exaggeration to say that it's *a lot* of boilerplate. It's one line or two in the base class.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Sure, it might be rare with methods, but don’t forget about properties! It makes perfect sense to have properties that should be only overridable internally while being accessible publicly.</blockquote><div class=""><br class=""></div><div class="">My first reaction here was: of course, good point! But then, on reflection, what properties should behave this way? Can you give an example of a property that makes sense to override in internal subclasses but not in external subclasses, but that must be accessible publicly?</div><div class=""> </div></div></div></div></blockquote><div><br class=""></div><div>Well, boilerplate is boilerplate. I can imagine a number of situations where you’d need it — any time where you can some sort of logical division in your class design, where some functionality relies on internal invariants that are no business of the user while functionality is tweakable. At the same time, after thinking about it for a while, I agree that such cases might be rare:</div><div><br class=""></div><div>1. If your class requires a lot of sealed members, then probably there is a better design somewhere that splits that class in multiple components. </div><div>2. If your members are overriden internally but sealed publicly, the performance argument seems to be diminished to me — the compiler still needs to do some sort of vtable dispatch if </div><div> the identity of the instance type is not known at compile-time. </div><div>3. I did a quick rudimentary regex through AppKit headers looking for stuff like "((n't)|(not)).{1,15}override“ and its true that there seem to be only a few dozens of documented methods where the documentation explicitly warns agains overriding them. I have no idea how reliable the headers are or what the documentation is generated from, but that appears to me to be quite strong evidence </div></div>in support of Károly’s and others arguments. <div class=""><br class=""></div><div class="">I still think that explicit open is a better design conceptually, as it requires one to grant per-declaration permission instead than per-declaration prohibition, but I agree that it might be a sub optional design from the practical standpoint because of low frequency of sealed members in practice. In retrospect, It might be indeed worth seriously considering making ‚open‘ a class-level annotation only. But then, there are good arguments for having an additional ‚sealed‘ keyword for the relatively rare case where we want to explicitly exclude a method/property from being overridable. </div><div class=""><br class=""></div><div class="">T.</div></body></html>