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

[Jose Cheyo Jimenez]

> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>>>> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2th at gmx.de> wrote:
>>>> 
>>>> Second:
>>>> Do you really believe there will be positive impact on open-source libraries?
>>>> My forecast is that closed by default will dramatically increase trivial pull request where developers ask for unsealing so that they can do as they like…
>>> 
>>> I think this is a good thing.  It will force a considered answer and a discussion about whether or not subclassing should be supported by the library.
>> 
>> So, let's say I ask you to support subclassing in your library, and you say no. What's to stop from just writing something like this:
>> class YesICan {
>>   var foo: YouCantInheritThis
>>   // Duplicate `YouCantInheritThis`'s public API by just passing everything through to `foo`
>> }
>> 
>> And overloading/extending anything else I need for `YesICan` to, functionally speaking, inherit from `YouCantInheritThis`.
> 
> You can certainly do this, but it isn’t equivalent to subclassing for at least two reasons.
> 
> First, calls within the methods of YouCantInheritThis will not call into the methods in YesICan. In other words if YouCantInheritThis has both doWork() and okIWill() methods and doWork() calls okIWill(), it will only ever call the implementation of okIWill() in YouCantInheritThis, not the implementation in YesICan. This actually gets to the heart of what one hopes to achieve through final or sealed, specifically avoiding a subclass from inadvertently changing the behavior of a superclass and assumptions the superclass is making about behavior of calls *within that superclass*.
> 
> Second, you cannot pass a YesICan where you can pass a YouCantInheritThis, so if you have another library that traffics in YouCantInheritThises, your “subclass” cannot be used with it.
>  
What if created a protocol 

YouCantInheritThisCloneProtocol{
// everything in sealed class
}

Then you extended the sealed class to conform to the clone protocol. 

Changed the other API that you have source to take a Clone Protocol derived object. 

This is getting out of hand :) but I think we need a middle ground somewhere. 





> Mark
> 
>> 
>> Yes, I know it'd all be the epitome of annoying boilerplate code, but my point is that if someone wants to subclass something of yours, there's really not much you can do to stop them.
>> 
>> (Before anyone mentions it, yes, the same trick can be used to get around `final` and `sealed`, but IIRC the motivations there were to enable certain compiler optimizations, not to prohibit "unauthorized" inheritance.)
>> 
>> - Dave Sweeris
>> _______________________________________________
>> 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