> On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote: >> > On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution >> > <swift-evolution@swift.org> wrote: >> > >> >> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution >> >> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
