> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution
> <[email protected]> wrote:
>
>
>> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>
>> Sent from my iPhone
>>>> On Jul 9, 2016, at 11:29, Matthew Johnson via swift-evolution
>>>> <[email protected]> wrote:
>>>>
>>>> On Jul 9, 2016, at 11:04 AM, Tino Heth <[email protected]> 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
>> [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
