<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><br></div><div>On Jul 5, 2016, at 7:11 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hello Swift community,</span><br><span></span><br><span>The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:</span><br><span></span><br><span> <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></span><br><span></span><br><span> * What is your evaluation of the proposal?</span><br></div></blockquote><div><br></div>-1<div><br></div><div>Perhaps because this is so different from what I have seen in other languages and used for so many years. I have not worked with a language that uses non-subclassable/ non-overridable as the default. </div><div><br></div><div>I think that by default classes should be subclassable, not the other way around. I am afraid that developers will not take the time to specify which methods are overridable resulting in libraries that are difficult to patch, extend. </div><div><br></div><div>In my 26+ years of object-oriented design and programming (other languages, Objective-C since 1990 and Java since 2001) I have worked with object oriented libraries and subclassed methods that the authors probably never anticipated. I have been able to fix problems, enhance classes by creating subclasses with fixes and enhanced behavior. </div><div><br></div><div>In java for example I have seen that sometimes I would have been able to fix bugs or enhance the existing classes had the author not chosen a method to be protected or private. Sometimes they had a good reason but sometimes they didn't. Is have been able to survive using an awesome library that was discontinued and end-of-lifed thanks to subclassing that has allowed me to fix problems and enhance over the years as the Java language kept evolving. </div><div><br></div><div>In general I like to design classes with methods that have a very well defined purpose / logic. Such methods are potentially overridable. I find that making a method private or final can be selfish / restrictive at times and I choose it carefully for implementation details that are better served by going through the public methods. </div><div><br></div><div>I think that making a class not subclassable by default is restrictive / limiting / selfish. </div><div><br></div><div>Sometimes the extension points are clear. </div><div>I also think that every other method with a well defined purpose / logic is also potentially an extension point. </div><div><br></div><div>In my experience we should allow the developer to override by default. That is how I design my classes and every method / property. </div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">I use private f</span>or the stuff that is obvious that should not be exposed. </div><div><br></div><div>In the motivation section <b>performance</b> is also mentioned as driving this proposal. However I don't see any study that supports that. I would like to see that. This should not be taken lightly. </div><div><br></div><div>Let's imagine that performance is important for a library that is heavily used and that the classes are not the type that you usually override. Wouldn't we be better served by being able to seal the class, i.e. "<b>public sealed class Foo</b>" and then for the methods / properties that are clear extension points should be flagged <b>overridable</b>. I would prefer something like that. And I think it would be more intuitive. </div><div><br></div><div><br><blockquote type="cite"><div><span> * Is the problem being addressed significant enough to warrant a change to Swift?</span><br></div></blockquote><div><br></div>No. </div><div><br><blockquote type="cite"><div><span> * Does this proposal fit well with the feel and direction of Swift?</span><br></div></blockquote><div><br></div><span style="background-color: rgba(255, 255, 255, 0);">I think it is counter-intuitive. I don't think that reading "<b>public class Foo</b>" would make anyone think that Foo is non-subclassable. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">On the other hand, reading "<b>public class sealed Foo</b>" would suggest to the reader that the class can be overridden but only the methods that are flagged as <b>overridable</b>. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">If we wanted to prohibit overriding then we could use "<b>public final class Foo</b>" without any extension points. Then nobody would be able to subclass and it would be an error to try to flag a method / property as overridable. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><br><blockquote type="cite"><div><span> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br></div></blockquote><div><br></div>I don't recall having seen this behavior in the languages that I have worked with. </div><div><br><blockquote type="cite"><div><span> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br></div></blockquote><br>I read the whole proposal and have been thinking about the implications for a few hours. </div><div><br><blockquote type="cite"><div><span>More information about the Swift evolution process is available at</span><br><span></span><br><span> <a href="https://github.com/apple/swift-evolution/blob/master/process.md">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br><span></span><br><span>Thank you,</span><br><span></span><br><span>-Chris Lattner</span><br><span>Review Manager</span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution-announce mailing list</span><br><span><a href="mailto:swift-evolution-announce@swift.org">swift-evolution-announce@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a></span><br></div></blockquote></div></div></body></html>