> On 15 Feb 2017, at 17:02, Matthew Johnson <[email protected]> wrote: > >> >> On Feb 15, 2017, at 9:59 AM, Rien <[email protected]> wrote: >> >>> >>> On 15 Feb 2017, at 16:45, Matthew Johnson <[email protected]> wrote: >>> >>>> >>>> On Feb 15, 2017, at 9:35 AM, Rien <[email protected]> wrote: >>>> >>>> >>>>> On 15 Feb 2017, at 16:11, Matthew Johnson via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy Pereira via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On 15 Feb 2017, at 11:11, Brent Royal-Gordon via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> Our philosophy in general, however, is to default to the behavior which >>>>>>> preserves the most flexibility for the library designer. >>>>>> >>>>>> Actually, I thought the philosophy was to preserver type safety. When >>>>>> did that change? >>>>>> >>>>>> Also, when was the library designer prioritised ahead of the application >>>>>> developer? >>>>>> >>>>>> >>>>>>> Both open and non-open classes are common, but we chose to give >>>>>>> non-open classes the `public` keyword because that's the >>>>>>> flexibility-preserving option. >>>>>> >>>>>> No it isn’t, it’s the flexibility restricting option. The consumer of an >>>>>> open class can subclass it. The consumer of a public class cannot >>>>>> subclass it. How is the second more flexible than the first? >>>>> >>>>> It reduces complexity for the library author by allowing them to opt-out >>>>> of the complexity involved in supporting unknown, user-defined >>>>> subclasses. It is important to allow libraries to have this flexibility. >>>>> They are free to declare a class `open` if they want to allow >>>>> subclassing. It’s even possibly for a library to declare all classes >>>>> `open` if it wishes to do so. But *requiring* that would reduce the >>>>> design space libraries are allowed to explore and / or introduce >>>>> fragility by moving the subclass restriction to a comment. >>>>> >>>> >>>> Why would a library author want to prohibit subclasses? >>>> A library user can always wrap the class and subclass the wrapper. >>> >>> This is composition, not inheritance. The most important difference is >>> that a wrapper cannot override methods, it can only wrap and / or forward >>> them. This means that when the superclass calls a method on `self` that >>> method *always* invokes its version of that method rather than a subclass >>> override. This is a very important difference. >>> >> >> Agreed, however that does not answer the question why would a library >> developer want to disallow subclassing? >> I do not see a use case for that. I.e. a feature that cannot be implemented >> without it. (without “open”) > > The feature it enables is more robust libraries and the ability for library > authors to better reason about their code. You may not find this benefit > enough to be worth a language feature, but many of us do.
You start of with a claim “more robust libraries”. I would really like to know the “how” of that. How does it make a library more robust? I do write libraries myself, and if there is something I am missing, I very much would like to know. Regards, Rien. > >> >> Rien. >> >>>> >>>> There are cases where subclassing does not make sense. And thus preventing >>>> subclasses adds information for those users that don’t RTFM. But that imo >>>> is not worth the impact extra complexity places on all other users. >>>> >>>> Rien. >>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
