To be fair and practical with the proposal it does not remove the ability to inherit any of the UIKit classes because all Objective-C classes are imported as "open". Food for thought on inheritance-is-the-only-fix, how have we worked all these years with C libraries like Security, Foundation, Core Graphics, GCD, and so on if C doesn't have inheritance? My point here is not to suggest anything other than to keep an open mind, the proposal is not removing OO from Swift. It is definitely a non conventional approach when compared to other languages, Kotlin is the only language with something similar but I have never used it. I have seen a lot of problems being solved by inheritance that could be solved by composition in a way that was more reliable, testable, and clear. When I asked why inheritance the answer is most of the time because that is the way they know how to do things, like it was the only tool available. I think Swift has as opportunity to increase software quality by providing good defaults that make developers understand what are the consequences of their choices. Maybe I'm too optimistic. On Thu, Jul 7, 2016, at 16:01, Aditya Krishnadevan via swift-evolution wrote: > 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- > [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 <swift- >> [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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
