> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > on Thu Jul 21 2016, Matthew Johnson <[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. 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]> > 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
