[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly
James Campbell
james at supmenow.com
Wed Jul 6 07:33:03 CDT 2016
-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160706/bd4c14f7/attachment.html>
More information about the swift-evolution
mailing list