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

[Leonardo Pessoa]

Just to relax a bit, from reading this thread I cannot help but feel a
relation to Civil War. One can even say on which side everyone here
would stand for real. #TeamIronMan

L

On 8 July 2016 at 15:13, Matthew Johnson via swift-evolution
<swift-evolution at swift.org> wrote:
>
>
> Sent from my iPad
>
> On Jul 8, 2016, at 12:30 PM, Tino Heth <2th at gmx.de> wrote:
>
>
> 1. As you point out, the majority of the surface area of idiomatic Swift
> APIs are unlikely to be impacted (value types, protocols, and final
> classes).  This is very likely to apply to future Swift-native APIs from
> Apple regardless of the outcome of this proposal.
>
> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT).
>
> In the context of these facts, this proposal is not nearly as dramatic a
> change as many seem to be suggesting.
>
> It is dramatic, and your whole argument is flawed because you miss the imho
> most important point.
>
>
> I didn't say it isn't dramatic, only that it isn't as dramatic a change as
> some commenters seem to suggest.
>
> This is not only a question of "will I be able to override this tiny method
> of UIView in the future?", but a question of attitude:
> When you do away with the rule of lenity and change it to "guilty by
> default", the direct impact is marginal as well — but it is a drastic change
> for the society as a whole.
>
>
> It's not about guilt or innocence, or any kind of lenience or punishment.
>
> It's mostly about whether we want to foster an ecosystem where public API
> contracts have been explicitly considered or not.  There are some ancillary
> benefits as well but those are much less important.
>
>
> Defaults matter, because they transmit a message:
>
>
> I agree.
>
> Every rule and obstacle we add to Swift is a statement that says "we favor
> bureaucracy over freedom", and this will affect the community evolving
> around the language.
> When you use a library in a way that wasn't anticipated by its author,
> you'll ran into issues occasionally; nonetheless, I think we should struggle
> for an open ecosystem that encourages others to experiment and fail, rather
> than to limit their possibilities in a futile attempt to protect them.
>
>
> In a majority of cases today this openness is better fostered by Github than
> "anything goes" public API.
>
>
> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that
> library had restricted my options to use it"?
>
>
> I really wish Objective-C had this feature from the start.  I believe there
> would have been significant benefits to Apple's platforms and ecosystem.
> The reasons for believing (or not believing) this have been discussed in
> depth so there isn't a need to rehash them now.
>
> As a matter of fact, open by default forces nobody to subclass and override,
> so it's easy to avoid any problems caused by excessive hacking — closed by
> default, on the other hand, has impact not only on those who believe in
> restrictions, but on those who dislike them as well.
>
>
> Actually open by default has caused some very nontrivial difficulties for
> Apple's framework maintainers.  We all pay the price for this whether we
> engage in such subclassing and overriding or not.  I find that pretty
> unfortunate, especially for those of us who do find other ways to solve our
> problems.
>
> -Matthew
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>