<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><span></span></div><div><div><span></span></div><div><div>2016/07/15 16:37、Riley Testut via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:</div><div><br></div><blockquote type="cite"><div><span>FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts:</span><br><span></span><br><span>• Open keyword is significantly better. </span><br><span>• Members should be *open* by default, and final should be opt-in. If you're opening up a class for subclassing, my gut says you should allow the client to do as they wish.</span><br></div></blockquote><div>If you have a class that was not open yet, just making it open wouldn't expose any members: it would then just be subclassable.</div><div><br></div><div>If the act of making the class open doesn't implicitly make overriding possible, well all you can do then is add methods, and that can be done with extensions anyways, so it's not as useful and makes the <i>public open class {}</i> pattern <i>just</i> by itself not so useful imho... 😬</div><div><br></div><div>Also, the keyword 'open' itself may imply 'hey I'm open, please do what you want with my public members', whereas 'subclassable' is more specific in intention... (but that's just me, so n=1 and all that)</div><div><br></div><div>TLDR; +1 to the above: simpler is better and defaulting to overridable for public members on an open class is simpler... invariants can be protected by the 'final' keyword.</div><div><br></div><div>If we were to default to non-overridable, a more consistent 'open' on the method is preferred over overridable for me... open class, open method... much better imho...</div><div><br></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"> If only one or two methods should be overridable, I think delegation (via protocols) is a much better solution.</span></font></blockquote></div><div>Delegation and protocols all the way!</div><br><blockquote type="cite"><div><span>• I feel like final and open are now *almost* on the same axis, but not quite; open controls subclassability outside module, but final controls it for both. Why not use access control modifiers, such as:</span><br><span></span><br><span>- public(open)</span><br><span>- internal(open) (default)</span><br><span>- fileprivate(open)</span><br><span>- private(open) = final</span><br><span></span><br><span>Then, we could remove the "final" keyword from the language completely, and use access control as normal. I feel like this unifies everything much better (private(open) does seem a little weird though).</span><br></div></blockquote><div>I think it does feel a little weird, and maybe makes things more complicated... for example, private(open) by itself doesn't tell me at a glance what consumers of the framework will see... maybe this because of the 'open' being there... it feels like just plain 'private' is better... then I can reason, 'oh this is only a private class, I'm the author so I can do what I want here' or 'oh, this ones public but not open'... maybe I'm wrong though.... 🙃</div><div><br></div><div>Thanks,</div><div><br></div><div>Andre</div><br><blockquote type="cite"><div><span>On Jul 15, 2016, at 1:27 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>On Jul 14, 2016, at 2:39 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>asks the community for an in-depth discussion of the secondary points of the proposal: does it make sense to require every member to be marked as “overridable” in order to be overridden by an open subclass outside of the current module?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>To be clear: You want this discussion to happen in the next review thread, rather than in this thread?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>Brent Royal-Gordon</span><br></blockquote><blockquote type="cite"><span>Architechies</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></body></html>