<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 20 Jul 2016, at 06:57, Jaden Geller <<a href="mailto:jaden.geller@gmail.com" class="">jaden.geller@gmail.com</a>> wrote:</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="">The keyword `open` would only be required to allow subclassing **outside** of the module. You will still be able to subclass inside the module as long as it isn’t marked as `final`.<div class=""><br class=""></div><div class="">This proposal wants classes to be `final`-by-default **outside** of the module and subclassable by default inside the module.</div><div class=""><br class=""></div><div class="">This is about making sure developers don’t accidentally release an API promising a more than they’re able to support. Once they decide that (a) a class won’t break when subclassed and (b) they’d like to support subclassing for that class until the next breaking change, they annotate the class with `open`.</div></div></div></blockquote><br class=""></div><div>Yeah, I very much do not support that. It creates additional complexity - all of these strange esoteric discussions we’re having about what should be, really, a pretty simple thing. I don’t want to have to remember all kinds of complicated rules what becomes ‘final’ and what becomes ‘open’ or what the defaults might be (if they’re not obvious) and how all of these other complex subclass rules apply. Just tag the things that can be subclassed - it’s all scoped to existing access scopes. Simple and easy to remember.</div><div><br class=""></div><div>@Peter: Yes, final would be implied on all classes. You would be able to “open” them to remove that restriction, and it would be scoped to existing access scopes (as we do already for setter visibility). I.e.:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>public internal(open) class MyAbstractBaseClass {</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// Contains some members which all fatalError()</div><div>}</div><div><br class=""></div><div>private MySpecialisedClass : MyAbstractBaseClass { </div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// Specialised stuff here</div><div>}</div></blockquote><div><br class=""></div>Compare with the modifiers for class members:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">public internal(set) myInternalVariable : Int32</div></blockquote><div class=""><br class=""></div><div class="">Not only that, but it’s immediately clear by looking at MyAbstractBaseClass who is subclassing it. Compare with an implicit internal open and non-implicit public open (as in the proposal):</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">public class MyAbstractBaseClass {</div><div class=""><br class=""></div><div class=""><div><span class="Apple-tab-span" style="white-space: pre;"> </span>// Contains some members which all fatalError()</div></div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">I think my suggestion improves local reasonability and simplifies the syntax requires considerably.</div><div class=""><br class=""></div><div class="">Like I said, I can’t see the reasoning behind limiting “open” to public classes. It’s just a concession to allow sloppiness inside of your own module, but even then - for complex internal classes with a mixture of overridable and non-overridable members, having to declare those “open” could even be of benefit. If it’s such a big problem, perhaps we can invent some kind of shorthand on the class attribute to declare all of its members overridable (like "open-all” or something).</div><div class=""><br class=""></div><div class="">Karl</div></body></html>