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

[Aditya Krishnadevan]

I agree with everything James has to say here. Making classes
non-subclassable by default is not optimal.
A lot of fixes for small bugs in UIKit involve using a subclass that
overrides at method or slightly modified behaviour as a temporary patch
until the issue is fixed at the framework level.
Preventing this *and* introducing a new keyword simply adds to the
complexity without bringing too much to the table.

Aditya Krishnadevan.

On 06-Jul-2016, at 6:03 PM, James Campbell via swift-evolution <
swift-evolution at swift.org> wrote:

-0.5 I think preventing subclassing is a bad idea, sometimes there are bugs
which can only be resolved by subclassing and this removes a lot of power
from app makers.

On 6 July 2016 at 13:23, Jacopo Andrea Giola via swift-evolution <
swift-evolution at swift.org> wrote:

> >       * What is your evaluation of the proposal?
>
> Unless someone can prove to me why we wouldn't need this for fixing bugs I
> still thing this is only a good system to hint at the developer that they
> shouldn't be using this class unless they have to.
>
> I could envision the compiler using the overide keyword to force the
> developer to acknowledge they are using a non-reccomended class like so:
>
> // This class implements a polyfill which fixes a bug in the keychain class
> override class PolyfillForKeychainBug: Keychain {
>
> }
>
> Without this the compiler would throw an error "Non-open class can't be
> overridden without `override` keyword"
>
> >       * Does this proposal fit well with the feel and direction of Swift?
>
> ​It does in terms of safety but not in terms of simplicity.​
>
>
> >       * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> ​It works like Java but I never liked final​
>
>

> >       * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I’ve read the proposal
> _______________________________________________
> 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/20160708/57409459/attachment.html>