I completely agree with rparada and give a strong, strong, strong -1 to this proposal. To make classes non-subclassable by default is only going to lead to unanticipated pain and frustration. Also agree with other comments that subclassable and overridable conflate access control with class behavior. If we want to make it possible to define a class as non-subclassable to external users, I’d agree to something more consistent with existing swift access control like public(final) as has been proposed by other commenters. However, I agree that making classes final by default is a bad idea that will create a larger problem that it solves.
Also, just a more general complaint, I sometimes feel that the evolution list is being dominated by safety enthusiasts at the expense of usability advocates. Safety is a premier feature of Swift, but so is usability. We should be trying to find solutions that advance both objectives, as well as performance and power. > On Jul 5, 2016, at 7:11 PM, Chris > Lattner<clatt...@apple.com(mailto:clatt...@apple.com)>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 sectionperformanceis 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 servedby 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 flaggedoverridable.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 > asoverridable. > > 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 > > swift-evolution-annou...@swift.org(mailto:swift-evolution-annou...@swift.org) > > https://lists.swift.org/mailman/listinfo/swift-evolution-announce > > > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
