[swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

[L. Mihalkovic]

Regards
(From mobile)

> On Jul 11, 2016, at 5:00 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jul 10, 2016, at 9:53 PM, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 2. The motivation seems to be that it will force better API design.
>> 
>> No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll address it.
>> 
>> Accepting this proposal won’t turn bad API designers into good ones. Crappy APIs are still going to be crappy with or without this. In the immortal quote apparently due to Lawrence Flon: “There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code.”
>> 
>> The justification for this proposal is all about supporting the people who are working to design library APIs right, and about maintaining consistency with the design philosophy of Swift. To wit: in Swift, where there’s a default choice, it’s the safe one; where there’s a consequential design decision, it’s explicit.
> 
> +1.  This is exactly why sealed is the default that fits best with the rest of the defaults in Swift.  They are permissive within a module and require explicit choices where external contracts are involved.
> 
>> 
>> Rod Brown hit the crux of it: sealed → open is safe for existing API clients, but open → sealed is a breaking change. “Sealed” is thus the safer choice, and “open” is a consequential design decision. Given the general precedent and philosophy of Swift, competent API designers might reasonably be taken aback that open is the default. In fact, given the habit Swift encourages of leaning on compiler verification, this is a potential source of designer error.
>> 
>> • • •
>> 
>> For those who think that discouraging inheritance by default is something recent, or a fad, or a quirk of Swift: Josh Bloch spent over 5 pages of Effective Java arguing against “subclassable just in case.” That was in 2001, and it was old news even back then.
>> 
>> Those looking for a more detailed analysis of the problems caused by APIs allowing inheritance without designing for it should read his analysis. It’s 15 years old, it’s Java, but it still stands. (He even gives instructions toward the end for simulating something very much like the here-proposed “sealed” in Java using package-private initializers.) It’s item 15 in the book, “Design and document for inheritance or else prohibit it.”
> 
> Agree.  The best practice has been around for some time, although it sounds like it is not yet widespread as it could be (especially in-depth knowledge of the rationale behind it).  
> 
> What is relatively new is the opportunity to embrace it in the design of a (sure to be) popular and widely used language that carries most of the traditional OO facilities.  This is a great opportunity IMO.

I find surprising to that one would sign up for what basically amounts to 'compiler take my freedom away as I do not feel I can bare the responsibility it places on me'. To me, Joshua Bloch's message was never as an appeal to the javac teams to suppress freedom, but to developers to become cognizant of its consequences and strive to write better code. But it seems to be a human trait throughout history to want to relinquish our individual freedom for the comfort of someone else being responsible.

>> 
>> Cheers,
>> 
>> Paul
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution