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

T.J. Usiyan griotspeak at gmail.com
Wed Jul 6 08:19:15 CDT 2016


+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 <
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/20160706/5e132433/attachment.html>


More information about the swift-evolution mailing list