<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I agree that it would make sense to be able to say "I allow subclasses, but they<br>don't get to override any of my methods unless I say so, even things I inherit".<br>But that feels like a refinement.</blockquote><div><br></div><div>Well, we can already achieve that by writing,</div><div><br></div><div> public final func f() -> Int { return _f() }</div><div> internal func _f() -> Int { return 42 }</div><div><br></div><div>That way subclasses in the module can override _f to change the behavior of f, while outside they cannot. So we can already accomplish “an open member of a base class is sealed by a subclass”.</div><div><br></div><div>What we *can’t* do, either now or with the proposal, is have a sub-subclass *re-open* that member:</div><div><br></div><div>open class A { open var x: Int //... }</div><div>open class B: A { override final var x: Int { return _x } }<br></div><div>open class C: B { override open var x: Int { return 16 } } // error: cannot override `final` member</div><div><br></div><div>For that we would need either an explicit `sealed` keyword, or the ability to override an `open` member as `public` (non-open), which class B could use here.</div><div><br></div><div>Nevin</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 4:22 PM, John McCall 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="gmail-h5"><blockquote type="cite"><div>On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">on Thu Jul 21 2016, John McCall <</span><a href="mailto:swift-evolution@swift.org" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">> wrote:</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite">On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution<br><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>on Thu Jul 21 2016, Matthew Johnson<br><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>>><br></blockquote><br><blockquote type="cite">wrote:<br><br><blockquote type="cite"><blockquote type="cite"><span style="white-space:pre-wrap"> </span>* What is your evaluation of the proposal?<br></blockquote><br>+1 to the first design. I think this is a great solution that<br>balances the many considerations that have been raised on all sides of<br>this issue. `open` is 2 characters shorter than `public` so<br>complaints about boilerplate are no longer valid. `internal` is the<br>“default” - neither `public` nor `open` are privileged as a “default”<br>for publishing API outside of a module.<br><br>I am interested in language enhancements such as exhaustive pattern<br>matching on classes and protocols which rely on knowledge of the full<br>class hierarchy. Such enhancements will be far more useful if the<br>language supports non-open, non-final classes.<br><br>There are design techniques that would require additional boilerplate<br>if we cannot have non-open, non-final classes.<br><br>Most importantly, requiring library authors to choose `public` or<br>`open` provides important documentation value. Users of the library<br>will know whether the author intends to support subclasses or not.<br></blockquote><br>I think this reasoning is flawed.<br><br>If you make any methods overridable outside your module (“open”),<br>obviously you mean to allow subclassing outside the module. If you have<br>no open methods, there's absolutely nothing you need to do to “support<br>subclasses,” and from a design point-of-view, there's no reason to<br>restrict people from subclassing.<br></blockquote><br>Superclasses can have superclasses, which can themselves have open methods.<br>This is, in fact, quite common for Cocoa programmers.<br></blockquote><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Okay, good point.</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Making a class non-subclassable seems like a pretty indirect way to say</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">“not even inherited methods should be overridden outside the defining</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">module,” though.</span></div></blockquote><blockquote type="cite"><div><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Wouldn't we prefer to have a way to hide the inheritance relationship</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">(and thus prevent overriding of inherited methods) outside the module?</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Or are these independently useful axes?</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></div></div>I agree that it would make sense to be able to say "I allow subclasses, but they</div><div>don't get to override any of my methods unless I say so, even things I inherit".</div><div>But that feels like a refinement.</div><div><br></div><div>John.</div><div><div class="gmail-h5"><div><br></div><div><blockquote type="cite"><div><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br>John.<br><br><blockquote type="cite"><br>The only reasons I can see for allowing people to prevent non-final<br>classes from being subclassed outside the module in which they are<br>defined are:<br><br>1. It feels like a nice point of control to have.<br><br>2. Marginal performance gains as noted in the proposal<br><br>I personally don't find these to be convincing. #1 in particular seems<br>like a poor way to make language design decisions. If we decide to add<br>this point of control, I'll justify it to myself in terms of #2.<br><br>P.S., I can live with either alternative; it's just important to me that<br>we understand the situation clearly when evaluating them.<br><br>HTH,<br><br>--<span> </span><br>Dave<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><<a href="mailto:swift-evolution@swift.org" target="_blank">mailto:swift-evolution@swift.org</a>><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br><<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br></blockquote>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br><br></blockquote><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">--<span> </span></span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">Dave</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">_______________________________________________</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">swift-evolution mailing list</span><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div></div></div><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>
<br></blockquote></div><br></div></div>