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`.
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
