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