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

[L. Mihalkovic]

Regards
(From mobile)

On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon <brent at architechies.com> 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.

It was not my intention to depict the intentions of the community but simply to state a couple facts. 1) Some proposal are born out of the evolution of another proposal, while others evolve as a subset of something more complex that needs to be broken down. This one did not, and was simply presented one morning. 2) The wwdc this year was very clear on the fact that one of the goals of the platform via swift is to put the language into the hands of non-professional programmers. The video was very well done and very inspirational. The new ipad playground app is a key part of this strategy, the other one being the language. The language has undergone great simplifications since the days of 1.xx with advanced features like tupple splatting or currying now removed, and confusing naming or constructs also gradually removed (3.0 is a very big step in ghat direction). 3) the core team was very clear that it is the direction they want for the language.

> 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
>