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

David Hart david at hartbit.com
Mon Jul 18 04:17:43 CDT 2016



> On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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? 

I don't know UIKit internals, but I could imagine loadViewIfNeeded be overridden internally, if one knows the precise internal workings of UIViewController. That would require open, to allow overriding internally but not externally.

>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/4aa8a469/attachment.html>


More information about the swift-evolution mailing list