+1 from me. I share similar concerns about 'easily' allowing subclassing within the module and testability but I am completely for this idea.
On Wed, Jul 6, 2016 at 8:33 AM, James Campbell via swift-evolution < [email protected]> 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 < > [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
