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

[Shawn Erickson]

Well stated and has pushed me into favoring the closed be default case. I
favor being explicit and the default being safe (you can always unseal in a
future revision if a need arises).

Also as you note it won't prevent bad implementations but it will help
library developers better bound their external surface and contract...which
if leveraged well will help with robustness, testability, and flexibility
in future revisions.

-Shawn

On Sun, Jul 10, 2016 at 10: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.
>
> 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.”
>
> Cheers,
>
> Paul
>
> _______________________________________________
> 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/19848426/attachment.html>