[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability
王 黎明
uomb at outlook.com
Fri Jul 22 07:31:19 CDT 2016
The problem is that: how to control/prevent the influence of customer’s code.
Question:
How the customer’s code influence the library?
For exam:
func apiNNNN(v:SuperClass) { … }
Customer call apiNNNN(v:aInstanceOfSubclass) { … } /* some function of SuperClass be overrided */
Is there any possibly for the following method:
func apiNNNN(@denyOverridedSubclass v: SuperClass) { … }
> 在 2016年7月22日,下午4:15,Dave Abrahams via swift-evolution <swift-evolution at swift.org> 写道:
>
>
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list