[swift-evolution] Final by default for classes and methods

[Matthew Johnson]

> On Dec 21, 2015, at 10:11 AM, Tino Heth <2th at gmx.de> wrote:
> 
>> 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.
> “I only believe in statistics that I doctored myself” - this quote is still true, and more than 95% of all statistic results are wrong ;-)
> No, seriously, there are several arguments to not overestimate the value of the poll:
> - There is bias in the form that you are more likely to view the poll submit a vote if you want final to be the default
> - I bet no one really calculated the percentage numbers, but rather choose a value that fits better to his preferred result
> - The poll starts with questions that filter out opponents that don't want to lie about their numbers (I could easily say I subclass everything just to change the numbers in favor of non-final… but that's not only unfair, but also easy to prove untrue :)
> 
>> "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.
> That's mostly building complicated numbers...
> 
>> 72.73% believe that final should be the default behavior.
> No, this is a simple number without much room for interpretation: Nearly 3/4 of all who took part on the poll (that is an important aspect) want final to be the default. But wait...
> 
>> 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`.
> Hu? Three choices, and two are just different names for the same? And the numbers don't add up to the same values??
> I can't see where "inheritable" is explained; naturally, I would take it as "you can extend what's already there, but not overwrite it"
> 
>> 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.  
> ah, ok - at least it's addressed
> 
>> 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.
> Which might be already the case — we are encouraged to use structs, and those can only be final.
> One major differentiation for classes is that they can be subclassed, and if that is not wanted, maybe a struct would be better anyways…
> 
> Nonetheless, I still would switch to the "final by default" camp if you have a convincing answer to a simple question:
> Why shouldn't inheritable (with the consequences outlined above) be the default? (if you read and answer at all, I'm fine when you discard the whole message if one this point is addressed…)

Hi Tino,

Thanks for taking time to respond.  I make no claims as to sound conclusions that can be drawn from the poll.  It is absolutely anecdotal.  I called out the unscientific nature of the poll right from the start.  You could be right about bias towards those who want final to be the default, but there are equally passionate people on the other side of this debate who may be motivated to respond as well.  It’s impossible to tell.

My conclusion states: "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.”  I don’t go any further than that.  But I do think it is wise to do this.  A lot of people are moving away from heavy reliance on inheritance in their Swift code.  Anecdotal data confirming this seems to be enough to warrant a closer look IMO.

You are correct that we can use value types in many cases and value types do not allow inheritance.  However, any Swift application is necessarily going to have a lot of classes as the Cocoa frameworks require apps to subclass framework classes in many instances.  Even when we are not required to subclass a framework class they often require our types to be a class, for example when we are providing a delegate to a Cocoa class.  These requirements of the frameworks result in a lot of classes in Swift applications that are not ever intended to be subclassed.

You ask why I don’t think `inheritable` should be the default.  I believe I have addressed that by making a case that it is less clear and less safe as a default.  Swift prioritizes safety and clarity so I believe the defaults should be influenced by those priorities.  If you have specific criticisms of the argument I presented I would like to know what they are.  Specifically, if you believe `inheritable` is a safer or more clear default I am very curious to hear why you believe that.

Thanks,
Matthew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/75d6a0f2/attachment.html>