[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly
karoly at lorentey.hu
Wed Jul 20 12:13:32 CDT 2016
> On 2016-07-18, at 19:05, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> The basic effect of Károly's counter-proposal is that every public member of an open class has to be marked either "open" or "final". That's boilerplate.
My primary point was that there is no need for a middle ground between "final" and "open" members.
I want to push my primary point a little more, so let’s forget my secondary suggestion to have no default, and let’s set an implicit choice.
I'd still argue for having no middle ground. “final” seems to be a good default; its effect matches the proposal.
> I think you and Károly are evaluating the addition of non-open methods as if they were being added primarily to increase expressive capabilities. They do marginally increase expressiveness, but I agree that it's not a common situation to explicitly want. However, neither are non-open classes.
It's more of an Occam's razor thing. The proposal prevents people from unintentionally exposing a wider API area than they intended. I agree with this wholeheartedly. I just don't believe that we need to add a brand new access level for members to achieve this goal.
Having an implicit "sealed" class level is a much easier sell for me, because it is sometimes desirable to expose a sealed class hierarchy, but Swift doesn't currently support it well -- AFAICT not as an intentional choice, but rather as an unfortunate side-effect of the initializer rules. You could've simply chosen to propose making "final" the default for public classes. Kotlin's troubles mostly wouldn't apply as long as internal classes would remain open, so I'd have supported that too. But rather than this, the proposal is built on top a nice solution to the sealed class problem. Solving it is obviously a good idea, and it is closely related to the goal of the proposal.
There is no such language problem in Swift 2 with sealed methods: an internal open member is sealed by virtue of not being externally visible. It’s straightforward to add a public final trampoline in the rare case when a sealed member should also be made externally callable. I believe the proposal works perfectly well without adding a language feature for this uncommon usecase.
> The goal here is not to create new expressive power, it's to establish a comprehensible intermediate position that's acceptable as a default so that publicizing an API doesn't require so much annotation and bookkeeping. Otherwise, programmers are forced to immediately decide between over-promising (by making the method publicly overridable) or breaking their own code (if they have internal overrides).
But making API public should never be done in a hurry. It includes making the API presentable, which involves some amount of refactoring. Granted, if an API has internally overridden methods that the author wants to make public but sealed, then they'd need to refactor these methods. But given how rare this is, and how easy it is to implement the trampoline pattern, is such a trivial refactoring step really too much to ask? (There are a number of much more complicated refactorings involved in making an API public; e.g., it is often the case that a method I want to make public has a parameter or return value with a type that I wish to keep internal.)
I believe that apart from this one little wrinkle, the behavior that SE-0117 proposes can be fully implemented by allowing just "final", "open" and "dynamic" members, with "final" being the default for public members of open classes, and "open" being the default for all other members (including non-open classes).
Is smoothing out that wrinkle worth introducing a whole new default level of member overridability? I think this is worth some more discussion.
Note that if we end up with "final” members by default and it turns out to be the wrong choice, changing the default to sealed would not be a source-breaking change.
> Furthermore, I don't agree that non-open methods add significant new complexity. For clients of a library, a non-open method is final; there are no semantically-detectable differences (ignoring covariant overrides). Within a library, non-open methods remove the need for some unnecessary bookkeeping. And just on a conceptual level, the analogy to class behavior is quite simple.
This reminds me: Whether or not we allow the sealed level on methods, I suggest we provide a contextual keyword to (optionally) spell it. A "sealed" keyword is the obvious choice. This would encourage people to use common terminology, and makes it easier to use search engines to find an explanation of the concept. Autogenerated API summaries should add the "sealed" keyword.
We never have to spell "internal", but I think it is still very useful that it exists.
More information about the swift-evolution