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

[Felipe Cypriano]

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-
> 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
> _________________________________________________
> 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/20160707/b0094db2/attachment.html>