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

[Dave Abrahams]

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.

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