[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Dave Abrahams]

on Thu Jul 21 2016, John McCall <swift-evolution at swift.org> wrote:

>> On Jul 21, 2016, at 1:04 PM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> on Thu Jul 21 2016, John McCall
>> <swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>>
>
>> wrote:
>> 
>>>> On Jul 21, 2016, at 10:47 AM, Dave Abrahams via swift-evolution
>>>> <swift-evolution at swift.org
>>>> <mailto:swift-evolution at swift.org>>
>>>> wrote:
>>>> on Thu Jul 21 2016, Matthew Johnson
>>>> <swift-evolution at swift.org
>>>> <mailto:swift-evolution at swift.org>
>>>> <mailto:swift-evolution at swift.org
>>>> <mailto: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.
>>> 
>>> 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
>>>> swift-evolution at swift.org
>>>> <mailto:swift-evolution at swift.org
>>>> <mailto:swift-evolution at swift.org>>
>>>> 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
>>> swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
>> -- 
>> Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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