[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly
Brent Royal-Gordon
brent at architechies.com
Mon Jul 18 03:27:00 CDT 2016
> 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.
--
Brent Royal-Gordon
Architechies
More information about the swift-evolution
mailing list