<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div style="font-family:Arial;">Strong +1 for me, separating access control from "open-to-subclasses" is a great feature. Leonardo's example of why final is not enough is great.<br></div>
<div style="font-family:Arial;"> </div>
<div style="font-family:Arial;">My stance is that Swift should be safe by default, predictable, and the compiler should know enough about the code to actually help me and this proposal fits this.<br></div>
<div style="font-family:Arial;"> </div>
<div style="font-family:Arial;">About testability, I don't think we should downplay how to test "sealed" classes from outside the framework. I do agree that the class should be treated as a black box with only public APIs available, but testing how my app is using those APIs should be possible somehow.<br></div>
<div style="font-family:Arial;"> </div>
<div style="font-family:Arial;">Last but not least, I don't like the proposed subclassable/overridable, specially because they imply public.<br></div>
<div> </div>
<div> </div>
<div>On Wed, Jul 6, 2016, at 12:35, Leonardo Pessoa via swift-evolution wrote:<br></div>
<blockquote type="cite"><div>Intention.<br></div>
<div> </div>
<div>IMO, intention may lead to more secure systems (and libraries). By<br></div>
<div>having to explicitly final everything I have to choose with parts of<br></div>
<div>my class/library would be locked and have to worry and check if any<br></div>
<div>public thing could be used to exploit it or make the system work in a<br></div>
<div>way I did not intended to. Also, final will prevent anyone including<br></div>
<div>me from extending/overriding. Defaulting to final would require from<br></div>
<div>me to explicitly declare the open endpoints in my libraries, so I<br></div>
<div>could explicitly open only the ones that are really intended to be<br></div>
<div>used in that way by third-parties.<br></div>
<div> </div>
<div>As an example, I'm working on a system which has an internal<br></div>
<div>representation of Files and Folders using a common superclass (lets<br></div>
<div>call it Entry). I would like for other developers to be able to create<br></div>
<div>new entry types (not only inheriting from File) but I do not wish for<br></div>
<div>them to extend from Folder or any of its subclasses (specialised<br></div>
<div>folders). By using final I can prevent others from extending my Folder<br></div>
<div>but I cannot extend it myself and thus need another mechanism for<br></div>
<div>achieving this behaviour without bloating the Folder class with all<br></div>
<div>its specialisations. This proposal would allow me to make my Folder<br></div>
<div>and its subclasses publicly available/usable but would prevent others<br></div>
<div>from subclassing and thus misusing them in ways I did not intend them<br></div>
<div>to. The same rationale applies to methods.<br></div>
<div> </div>
<div>L<br></div>
<div> </div>
<div>On 6 July 2016 at 16:09, Goffredo Marocchi <<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>> wrote:<br></div>
<blockquote><div>Leonardo, how is defaulting to final/sealed helping you write better libraries than having a final keyword for what you need to close instead?<br></div>
<div> </div>
<div>Sent from my iPhone<br></div>
<div> </div>
<div>On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<blockquote><blockquote><div>The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:<br></div>
<div> </div>
<div> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a><br></div>
<div> </div>
<div> * What is your evaluation of the proposal?<br></div>
</blockquote><div> </div>
<div>+1. Being able to control how a class from my libraries are going to<br></div>
<div>be used by third-parties could enable a better designed API with more<br></div>
<div>control of how it is intended to be used. I'm just not fond of using<br></div>
<div>the proposed keywords ('subclassable' and 'overridable') as they feel<br></div>
<div>more like protocol or attribute names; I'd be more inclined to use the<br></div>
<div>alternative 'public open' instead, or 'public(open)' as a second<br></div>
<div>option.<br></div>
<div> </div>
<blockquote><div> * Is the problem being addressed significant enough to warrant a change to Swift?<br></div>
</blockquote><div> </div>
<div>I'd say it is significant to every language.<br></div>
<div> </div>
<blockquote><div> * Does this proposal fit well with the feel and direction of Swift?<br></div>
</blockquote><div> </div>
<div>Yes.<br></div>
<div> </div>
<blockquote><div> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></div>
</blockquote><div> </div>
<div>C# uses the keyword 'virtual' to explicitly mark methods that can be<br></div>
<div>overriden (not considered in the alternatives but I'm not a big fan of<br></div>
<div>it).<br></div>
<div> </div>
<blockquote><div> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></div>
</blockquote><div> </div>
<div>I've took (a small) part on the thread discussing this proposal but<br></div>
<div>followed it closely<br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote></blockquote><div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div style="font-family:Arial;"> </div>
</body>
</html>