> 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”) 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
