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

[Karl]

> On 6 Jul 2016, at 01:11, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" begins now and runs through July 11. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> ...
> 	* What is your evaluation of the proposal?

+1. I really enjoy designing elegant, well-defined APIs and this behaviour for classes has bothered me for some time.

On the other hand, I have also subclassed things that weren’t meant to be subclassed (e.g. I believe UITabBar was an awkward one back in the day, and UINavigationController has so many broken behaviours it’s almost a requirement to subclass and patch it, even though I believe Apple disapproves). I could fall back to Objective-C, but that’s an implementation detail. In some theoretical future with an all-Swift UIKit, what do I do about those issues?

After thinking about it, I decided that in this theoretical future, no App would be able to use those hacks, and so all Apps would have the same broken behaviours and degrade the quality of the platform to such an extent that Apple is forced to do something about it. Ultimately, that’s exactly what we want; they need to see broken Apps everywhere in order to prioritise fixes. That improves code quality all-around.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yup

> 	* Does this proposal fit well with the feel and direction of Swift?

Yup, but I don’t like “subclassable class”. My preferences are:

#1 - “extendable class”    // explicitly clear about what I’m allowing
#2 - “open class”             // this is a bit vague - open how? How is it different from public?


> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I prefer this over “sealed”. Making classes extendable requires careful consideration, and should be explicit.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read through it a few times, and also the discussion last week. The problem has bugged me for a long time, and this is a pretty straightforward solution that integrates well with Swift (providing the keyword changes =] )

> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 

My pleasure!

Karl