> On Jul 5, 2016, at 7:11 PM, Chris Lattner <[email protected]> wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > > * What is your evaluation of the proposal?
-1 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. 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. 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. 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. 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. I think that making a class not subclassable by default is restrictive / limiting / selfish. Sometimes the extension points are clear. I also think that every other method with a well defined purpose / logic is also potentially an extension point. In my experience we should allow the developer to override by default. That is how I design my classes and every method / property. I use private for the stuff that is obvious that should not be exposed. In the motivation section performance 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. 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. "public sealed class Foo" and then for the methods / properties that are clear extension points should be flagged overridable. I would prefer something like that. And I think it would be more intuitive. > * Is the problem being addressed significant enough to warrant a change to > Swift? No. > * Does this proposal fit well with the feel and direction of Swift? I think it is counter-intuitive. I don't think that reading "public class Foo" would make anyone think that Foo is non-subclassable. On the other hand, reading "public class sealed Foo" would suggest to the reader that the class can be overridden but only the methods that are flagged as overridable. If we wanted to prohibit overriding then we could use "public final class Foo" 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. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I don't recall having seen this behavior in the languages that I have worked with. > * How much effort did you put into your review? A glance, a quick reading, > or an in-depth study? I read the whole proposal and have been thinking about the implications for a few hours. > More information about the Swift evolution process is available at > > https://github.com/apple/swift-evolution/blob/master/process.md > > Thank you, > > -Chris Lattner > Review Manager > > _______________________________________________ > swift-evolution-announce mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
