> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > on Thu Jul 21 2016, John McCall <[email protected] > <mailto:[email protected]>> wrote: > >>> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> on Thu Jul 21 2016, Matthew Johnson >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[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. >> >> Superclasses can have superclasses, which can themselves have open methods. >> This is, in fact, quite common for Cocoa programmers. > > Okay, good point. > > Making a class non-subclassable seems like a pretty indirect way to say > “not even inherited methods should be overridden outside the defining > module,” though. > > Wouldn't we prefer to have a way to hide the inheritance relationship > (and thus prevent overriding of inherited methods) outside the module? > Or are these independently useful axes?
I agree that it would make sense to be able to say "I allow subclasses, but they don't get to override any of my methods unless I say so, even things I inherit". But that feels like a refinement. John. > >> >> >> John. >> >>> >>> The only reasons I can see for allowing people to prevent non-final >>> classes from being subclassed outside the module in which they are >>> defined are: >>> >>> 1. It feels like a nice point of control to have. >>> >>> 2. Marginal performance gains as noted in the proposal >>> >>> I personally don't find these to be convincing. #1 in particular seems >>> like a poor way to make language design decisions. If we decide to add >>> this point of control, I'll justify it to myself in terms of #2. >>> >>> P.S., I can live with either alternative; it's just important to me that >>> we understand the situation clearly when evaluating them. >>> >>> HTH, >>> >>> -- >>> Dave >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> <mailto:[email protected] <mailto:[email protected]>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> <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> >> > > -- > Dave > > _______________________________________________ > 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
