> On Feb 15, 2017, at 10:35 AM, Rien <[email protected]> wrote: > >> >> 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.
This topic was well explored during the discussion and review of the proposal that introduced `open`. If you would really like to know I suggest you take some time to read through that discussion. > > 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] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
