[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic]

Regards
(From mobile)

> On Jul 11, 2016, at 9:43 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner <clattner at 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
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
>> 
>>         https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>>         * What is your evaluation of the proposal?
> 
> +1. As a big proponent of API reviews for code that's going to end up being used by others, I think sealed-by-default forces authors to think about how their code might end up being used by others more so than more-permissive alternatives

Believing that joe lambda devs might think about their code more because the compiler is going to prevent certain obscure behavior from happening seems IMHO like a blattant negation of what history tells us about human nature. Given 2 choices, most of us will choose the one involving the least amount of thinking or work; and given 2 choices with different amount of responsibilities, most of use will choose the least amount of perceived individual responsibility. Psychology 101, demonstrated in many experimentations.

Doing it because the core team wants to do it has the merrit of recognizing that in the end, they hold the keyboard and should be free to write whatever they fancy, regardless of where the choir sings. Simple and clear.
Design by consensus is the worst form of design, and the Linux kernel would never have made it to where it is today if Linus had not ignored what he had to when he had to. Happens what must happen.. and there should be no need for the half baked logic that has sometimes been invoked.

> . Seeing a keyword that marks a class as unsealed is a good opportunity to start a conversation in a code review.

I have honestly never seen ios devs doing that, including in large corps. Most devs I met were lone guys or small shops working on several things in parallel, with no code review and much less discussions about software design. 

> Given that Swift tries to encourage the use of value types over reference types in many places, which can't be subclassed anyway, I don't think this change should be a significant burden. I'm in the process of implementing a fairly large library that's about 95% value types and 5% reference types. The reference types are more of an implementation detail than a hierarchy of types, so I would have them be final anyway. This is completely anecdotal, of course, but it's a testament IMO to how differently Swift has me thinking about the way I structure my APIs, and subclassing has been mostly replaced by protocol extensions and composition.
> 
> I'm not compelled by the arguments that we need subclassing to fix bad APIs, because that's absolutely not what subclassing is intended for. It's a hack, and it's not a cure-all—it relies on being able to override the correct methods and inject custom behavior in the first place. The argument shouldn't be "we need open subclassing or we can't fix broken APIs"; that's a false choice. It should be "we need *something* to fix broken APIs", and that "something" should be proposed and the need for it should be argued in its own right. The ability to fix a sealed broken API does have value, but it is inherently unsafe because you might be making assumptions about pre/post-conditions that the original class author didn't think about, and those assumptions could become invalid in the future (or might rely on internal implementation details that you cannot predict). Rather than abusing a construct that is not suited for that purpose, those arguing for the need for that functionality should propose something more appropriate. This would be a win-win; we'd have a clean way of expressing API boundaries, and an unsafe-but-acknowledged-as-such way of hooking into APIs if a trap door is needed. (Of course, with Swift at such a young age, it's hard to know what the needs for that are until we have some more mature libraries to present as use cases.)
> 
>  
>>         * Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes.
> 
>  
>>         * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes. The behavior that classes are unsealed within the same module but sealed by default outside the module aligns nicely with the way internal visibility already works in the language. Newcomers and app developers don't have to think about it, but those who want to release code for others to use must; I think that's the right level of responsibility.
> 
>  
>>         * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>         * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Read the proposal and followed the heated discussion in the review thread.
> 
>  
>> 
>> 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-announce at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/65f51ef4/attachment.html>