on Thu Jul 21 2016, John McCall <[email protected]> wrote: >> 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.
A refinement of what? To me, “I don't allow any overrides outside my module” is a much more useful thing to be able to say than “I don't allow subclasses.” If we made “open” on a class mean that it's possible to override methods in other modules, then it would acheive that purpose, and it would leave “open” with a consistent meaning related only to overriding. > > > 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 > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
