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

[John McCall]

> On Jul 21, 2016, at 10:47 AM, 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:
> 
>>> 	* 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.

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>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/8741a15c/attachment.html>