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

[Xiaodi Wu]

On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Is there a summary somewhere of the motivation for allowing methods to
> be declared non-overridable within open classes?
> >
> > Because 1) someone woke up one morning and thought it would be great 2)
> it goes into the direction of making swift a language for non programmers
> 3) the core team wants it
>
> Laurent: This is not a fair characterization of the actual position of the
> proposal's supporters. If you can't be civil about this topic, perhaps you
> shouldn't be discussing it at all.
>
> Garth: I think it's implicit in the reasons to prevent subclassing. The
> mere fact that a class allows subclassing doesn't necessarily mean that
> every member in it is designed to be subclassed. Consider
> `UIViewController`: It's obviously designed to be subclassed, and some
> methods in it (such as `loadView`) are intended to be overridden, but
> others (such as `loadViewIfNeeded`) are *not* intended to be overridden.


And [if UIViewController were to be written in Swift] there'd be a good
reason why `loadViewIfNeeded` and others of its ilk couldn't be final?


> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> 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/20160718/ba535f7e/attachment.html>