[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability
Dave Abrahams
dabrahams at apple.com
Thu Jul 21 15:13:36 CDT 2016
on Thu Jul 21 2016, Matthew Johnson <swift-evolution at swift.org> wrote:
>> On Jul 21, 2016, at 12:47 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>> on Thu Jul 21 2016, Matthew Johnson <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
More information about the swift-evolution
mailing list