on Thu Jul 21 2016, Karl <razielim-AT-gmail.com> wrote: >> On 21 Jul 2016, at 22:13, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Thu Jul 21 2016, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> > >>>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>> on Thu Jul 21 2016, Matthew Johnson <[email protected]> wrote: >>>> >>> >>>>>> * What is your evaluation of the proposal? >>>>> >>>>> +1 to the first design. I think this is a great solution that >>>>> balances the many considerations that have been raised on all sides of >>>>> this issue. `open` is 2 characters shorter than `public` so >>>>> complaints about boilerplate are no longer valid. `internal` is the >>>>> “default” - neither `public` nor `open` are privileged as a “default” >>>>> for publishing API outside of a module. >>>>> >>>>> I am interested in language enhancements such as exhaustive pattern >>>>> matching on classes and protocols which rely on knowledge of the full >>>>> class hierarchy. Such enhancements will be far more useful if the >>>>> language supports non-open, non-final classes. >>>>> >>>>> There are design techniques that would require additional boilerplate >>>>> if we cannot have non-open, non-final classes. >>>>> >>>>> Most importantly, requiring library authors to choose `public` or >>>>> `open` provides important documentation value. Users of the library >>>>> will know whether the author intends to support subclasses or not. >>>> >>>> I think this reasoning is flawed. >>>> >>>> If you make any methods overridable outside your module (“open”), >>>> obviously you mean to allow subclassing outside the module. If you have >>>> no open methods, there's absolutely nothing you need to do to “support >>>> subclasses,” and from a design point-of-view, there's no reason to >>>> restrict people from subclassing. >>> >>> I disagree. As has been discussed when a class is not open the author >>> does not make a commitment to allow subclasses. >> >> Yes, but that argument is based on the *assumption* that disallowing >> subclassing is somehow an important dimension of safety or preserving >> API contracts, independent of overriding. It isn't. ^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Demonstration: we don't make that argument about aggregation: you can't >> prevent someone from making your public struct a stored property in a >> type defined outside the module. Judgements about programming style >> aside, in the absence of overriding, subclassing and aggregation are >> identical from an encapsulation point-of-view. >> > > IMO, the safety of API contracts is secondary. This is about safety of > implementation - my code is possibly not "resilient" enough (to to > speak) to handle overriding arbitrary public members.
I wrote that subclassability is not an important element of safety **independent of overriding**. If you don't allow any overriding, your code is always “resilient” enough to handle subclassing. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
