<div dir="ltr">> limiting “open” to public classes only lets you be sloppy inside your own module.<div><br></div><div>I don't find that idea bad actually.</div><div><br></div><div>In the similar vein one can say "it's ok to be sloppy with local variable names, it's not ok to be sloppy with instance variable names".</div><div><br></div><div>Again, tradeoffs. You can require that things are perfect, so that all methods are thoughtfully annotated, and all variables have wonderful self-descriptive names, but you'll get most bang for the buck by requiring that for the interface (public classes / instance variables) rather than for the implementation (non-public classes / local variables).</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 12:26 AM, Karl via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 20 Jul 2016, at 11:07, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br>
><br>
>> On Jul 19, 2016, at 6:14 PM, Karl <<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>> wrote:<br>
>><br>
>> That is to say, we basically introduce “open" as an inverted “final”, and make all classes non-open by default. That is analogous to enabling whole-module-optimisation by default, in my opinion. The cost of an extra four-letter word isn’t that great, but the benefits to readability and reasonability all-around make it worthwhile.<br>
><br>
> Okay, but this ignores an important difference between sealed and final.<br>
><br>
> Sealed is *non-committal*. It makes no promises to wider scopes about whether there are other subclasses/overrides; it merely states that code outside the module may not subclass/override. `final`, on the other hand, is an *affirmative* statement: there are no subclasses/overrides and there never will be. Code outside the module is permitted to rely on that fact—for instance, it can generate static calls and conflate dynamic Self with static Self in conformances.<br>
><br>
> But this distinction only really makes sense at the `public` boundary, because that's where the compiler—and even the developer—faces an impenetrable encapsulation barrier. If you want to require `open` even on non-public declarations, you thus need to choose one of these designs:<br>
><br>
> 1. `final` is still available, but only on public APIs.<br>
><br>
> 2. All non-public classes have to be explicitly declared either `open` or `final`.<br>
><br>
> 3. Sealed has some sort of complex, scope-specific design (for instance, an `internal` class can be subclassed in `fileprivate` but not in `internal` scope).<br>
><br>
> Of these three, I think that #2 is overly bureaucratic and #3 is overly complicated, so only #1 is a viable option. And then we're just choosing whether we have internal subclassing by default and an odd public-only `open` keyword, or no internal subclassing by default and an odd public-only `final` keyword. No viable option avoids some kind of asymmetry at the `public` boundary.<br>
><br>
> Open-by-default with a `final` keyword is the traditional design. It is simpler for people learning to program and more familiar for people new to Swift. It is more convenient. And you just don't need the same rigorous, formal definition of semantics in internal scope, where you can alter a problematic invariant rather than having to live with it.<br>
><br>
> All that said, there most likely *is* value in declaring, even internally, which classes are meant to be subclassed and which members are meant to be overridden. Perhaps what we ought to do is permit `open` even on non-public APIs, but not enforce it (or rather, leave enforcement to linters). That would allow people and teams to explicitly document internal overriding behavior if they want to, without burdening the teams that don't want to go to the effort.<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
<br>
<br>
</span>This is exactly what I'm talking about - this is actually a very simple discussion. Throwing around words like “non-committal” and “affirmative” and speaking abstractly doesn’t disguise the brunt of what you’re saying: limiting “open” to public classes only lets you be sloppy inside your own module. That’s the only reason to make it like that. If I were describing the concept of “sloppiness” while trying my hardest not to use the word itself, I would probably say pretty much what you just wrote - wanting to remain non-committal, avoid definite, affirmative statements, etc.<br>
<br>
If we think it is important for people who write classes to locally reason about their code, it’s important full stop. The conflation between if it’s publicly accessible and whether or not is a staggeringly massive regression in read&reason-ability, no matter how matter how you want to phrase it. It’s a general problem which deserves a general solution - not some ‘non-committal’ proposal which can't even commit to the problem it is trying to help with.<br>
<br>
If you’ve ever had to deal with complex base classes, consisting of a mixture of internal (and possibly internally subclassed) members and public ones, you would know that annotating which members are to be used by what (and knowing that it’s enforced by the compiler) would be a massive improvement to our language syntax. Sometimes you didn’t write all the code you have to work with, so it’s handy to have code which annotates this stuff.<br>
<br>
<br>
Karl<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>