As I mentioned earlier, Erica Sadun was kind enough to add a poll about this topic to her recent blog post (Naturally final classes in Swift — Erica Sadun <http://ericasadun.com/2015/12/18/naturally-final-classes-in-swift/>). There have been 70 respondents so far: https://www.surveymonkey.com/results/SM-FVQPXQ3J/ <https://www.surveymonkey.com/results/SM-FVQPXQ3J/>. This is obviously not a scientific sample and is not too large, but it is probably enough to give some sense of how inheritance is used by app developers as well as their opinions about final as default.
Here are some of the results I find especially worth noting: "What percent of the classes you write are subclasses of classes other than Apple provided framework or open source library classes?” 66.67% indicate such subclasses only comprise 0-20% of the classes they write. 14.49% indicate such subclasses comprise 20-40% of the classes they write. We also asked the inverse question "What percent of the classes you write are written with the intent that you will subclass them elsewhere in your app?” 80.00% indicate that only 0-20% of the classes they write are intended to be superclasses (subclassed elsewhere in the app). 7.14% indicate that 20-40% of the classes they write are intended to be superclasses (subclassed elsewhere in the app). 72.73% believe that final should be the default behavior. 48.48% prefer an `inheritable` keyword when inheritance is intended. An additional 15.15% prefer a `nonfinal` keyword for this behavior. 64.15% prefer one of the two. Only 36.36% prefer the current state of using `final`. Obviously there are slight differences between questions that are effectively asking the same thing. My guess is that this can be attributed to misunderstanding of the question in some cases. The data points to a strong trend. Most classes written by respondents at the app level are not intended to be subclassed. Aligning with this trend in frequency, most of the respondents would prefer final to be the default behavior. I have seen two arguments consistently emerge against making final the default. The first of those arguments is coming from a vocal group of app developers (possibly a vocal minority if the survey is any indication) who want to be able to subclass Apple frameworks to work around bugs. This argument is effectively making a moot point if we are already moving towards a `sealed` default. In any case, many of the framework classes are intended to be subclassed by developers and will be marked `inheritable` or similar allowing this to continue. Furthermore, as Jordan noted it isn’t really safe to make a class `final` retroactively. Because of this it is unlikely that current framework classes will be impacted by a change to `sealed` or `final` in the near term. This is likely to be a long-term transition. The other argument is that inheritance is a useful feature and requiring people to opt-in to it in their own code is going to be annoying. I find this argument somewhat surprising in a language that values safety and clarity. Safe use of inheritance requires thoughtful design. Allowing inheritance by default is less safe. It is also less clear because the code offers no indication of whether the author designed for inheritance or not. This fact is recognized in "error of omission” arguments for making `sealed` the default. It applies no less to code within our own app or module. Problems may be easier to fix in that case, but why not make them easier to avoid in the first place? The comparison with access control is not a great one IMO, especially if the survey data is indicative of wider patterns. I haven’t done any analysis, but my instinct is that internal is the correct access level more often than private. A reasonable debate could probably be held as to whether it is more problematic to access members that should be private elsewhere in the same module or to inherit from a class that wasn’t really designed for subclassing. That said, my experience and intuition says inheritance is quite a bit more problematic. IMHO reducing annoyance and bookkeeping in what is arguably a significant minority of cases is a pretty weak argument for sacrificing what I strongly believe is increased clarity and safety. The argument is even weaker if a majority of developers would prefer the safety and clarity of making `final` the default. Ironically, a default of `final` is actually less annoying and less bookkeeping for developers desire clarity in their code enough to add `final` where that is actually the intent if most of the classes they write are indeed leaves of the inheritance hierarchy. It is my hope that the data gathered in the survey will have some influence on this discussion. At a minimum I hope it encourages us to look deeper at this issue and gather additional data to find out whether the pattern identified by the survey holds more broadly. Matthew > On Dec 19, 2015, at 9:21 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > >> >> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>>> Defaults of public sealed/final classes and final methods on a class by >>>> default are a tougher call. Either way you may have design issues go >>>> unnoticed until someone needs to subclass to get the behavior they want. >>>> So when you reach that point, should the system error on the side of rigid >>>> safety or dangerous flexibility? >>> >>> This is a nice summary of the tradeoff. I strongly prefer safety myself >>> and I believe the preference for safety fits well with the overall >>> direction of Swift. If a library author discovers a design oversight and >>> later decides they should have allowed for additional flexibility it is >>> straightforward to allow for this without breaking existing client code. >>> >>> Many of the examples cited in argument against final by default have to do >>> with working around library or framework bugs. I understand the motivation >>> to preserve this flexibility bur don't believe bug workarounds are a good >>> way to make language design decisions. I also believe use of subclasses and >>> overrides in ways the library author may not have intended to is a fragile >>> technique that is likely to eventually cause as many problems as it solves. >>> I have been programming a long time and have never run into a case where >>> this technique was the only way or even the best way to accomplish the task >>> at hand. >>> >>> One additional motivation for making final the default that has not been >>> discussed yet is the drive towards making Swift a protocol oriented >>> language. IMO protocols should be the first tool considered when dynamic >>> polymorphism is necessary. Inheritance should be reserved for cases where >>> other approaches won't work (and we should seek to reduce the number of >>> problems where that is the case). Making final the default for classes and >>> methods would provide a subtle (or maybe not so subtle) hint in this >>> direction. >>> >>> I know the Swift team at Apple put a lot of thought into the defaults in >>> Swift. I agree with most of them. Enabling subclassing and overriding by >>> default is the one case where I think a significant mistake was made. >> >> Our current intent is that public subclassing and overriding will be locked >> down by default, but internal subclassing and overriding will not be. I >> believe that this strikes the right balance, and moreover that it is >> consistent with the general language approach to code evolution, which is to >> promote “consequence-free” rapid development by: >> >> (1) avoiding artificial bookkeeping obstacles while you’re hacking up the >> initial implementation of a module, but >> >> (2) not letting that initial implementation make implicit source and binary >> compatibility promises to code outside of the module and >> >> (3) providing good language tools for incrementally building those initial >> prototype interfaces into stronger internal abstractions. >> >> All the hard limitations in the defaults are tied to the module boundary >> because we assume that it’s straightforward to fix any problems within the >> module if/when you decided you made a mistake earlier. >> >> So, okay, a class is subclassable by default, and it wasn’t really designed >> for that, and now there are subclasses in the module which are causing >> problems. As long as nobody's changed the default (which they could have >> done carelessly in either case, but are much less likely to do if it’s only >> necessary to make an external subclass), all of those subclasses will still >> be within the module, and you still have free rein to correct that initial >> design mistake. > > I think John summarized my position very well, so of course I'm going to come > in here and add more stuff. :-) > > In working on the design for library evolution support ("resilience"), we've > come across a number of cases of "should a library author be able to change > this when they release v2 of their library?" Many times, the answer is it's > possible to do something in one direction, but not at all safe to go the > other way. For example, you can always add public methods to a class, but you > can't remove public methods because you don't know who's calling them. You > can mark them deprecated, but that doesn't help with any client apps that > have already been compiled and shipped. > > One of the things that came up was "can you add 'final' to a class?" And of > course you can't, because you don't know who may have already subclassed it. > That's very unfortunate for a library author who simply forgot to add 'final' > when they were first writing the class. > > The interesting thing about this is that the "error of omission"—of failing > to think about whether a class should be final—is worse than the alternative. > Ignoring optimizations for a minute, a class that starts out 'final' can > certainly become non-final later; it doesn't change how the class is > currently used.* For a lot of library evolution questions, this is the > preferred answer: the default should be safe, and the designer of the class > can choose to be more aggressive later. > > This is also the guiding principle behind the behavior of 'public'. A number > of people have asked for members of a public struct to implicitly be made > public. But here again the "error of omission" is problematic: a helper > function you add for your own use may now be depended on by client apps far > and wide, just because you forgot to customize the access control. So Swift > says you should explicitly consider the public interface of every type. > > Why 'sealed' instead of 'final' as the default? Because inheritance is > useful, and within your own code having to opt into it starts to feel like > unnecessary clutter. This is a trade-off, just like defaulting to 'internal' > over 'private', but it's one that keeps life easy for a single developer with > a single module: their app. (And the compiler can still do useful things with > non-final classes if it can see the entire class hierarchy.) Additionally, > limiting inheritance to the current file (a la 'private') is also potentially > useful. > > This direction separates "limiting inheritance/overrides" from "has no > subclasses/overrides". The former is about defining the limits of your API; > the latter is a promise that can be used for performance. I think that's a > good thing. > > Jordan > > * Even without optimizations a 'final' class cannot safely drop the 'final'. > If a class is 'final', it may have additional 'required' initializers added > in extensions. > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
