on Thu Jul 21 2016, Matthew Johnson <[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. > The right to make the class final is reserved for the future. Maybe > this is the “nice point of control” you refer to and don’t find > compelling? I would prefer to have library authors acknowledge that > they intend to allow subclasses and make that commitment explicit. The question is, why? > For me it isn’t about control as much as it is about making the API > contract explicit and acknowledged. I have wondered about the intent > of library authors enough times to find this explicit statement in the > language worthwhile. Yeah, but we don't add language features to represent every possible author intention, and there's a good argument that any intention that can be violated without harm shouldn't be enforced. > I also think language features enabled by knowing the whole class > hierarchy will provide more value than “compositional subclasses” as > long as we gain better support for composition elsewhere in the > language. I agree that there are better ways to solve the composition/API forwarding problem. >> 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. > > I agree with this. > >> >> HTH, >> >> -- >> Dave >> >> _______________________________________________ >> 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 -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
