[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability
Dave Abrahams
dabrahams at apple.com
Fri Jul 22 03:15:51 CDT 2016
on Thu Jul 21 2016, Karl <razielim-AT-gmail.com> wrote:
>> On 21 Jul 2016, at 22:13, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>> on Thu Jul 21 2016, Matthew Johnson <swift-evolution at swift.org <mailto: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.
>>
>
> IMO, the safety of API contracts is secondary. This is about safety of
> implementation - my code is possibly not "resilient" enough (to to
> speak) to handle overriding arbitrary public members.
I wrote that subclassability is not an important element of safety
**independent of overriding**. If you don't allow any overriding,
your code is always “resilient” enough to handle subclassing.
--
Dave
More information about the swift-evolution
mailing list