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