[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Taras Zakharko]

> On 18 Jul 2016, at 18:31, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> At the same time, your solution results in a lot of unnecessary boilerplate.
>  
> It's an exaggeration to say that it's *a lot* of boilerplate. It's one line or two in the base class.

> Sure, it might be rare with methods, but don’t forget about properties! It makes perfect sense to have properties that should be only overridable internally while being accessible publicly.
> 
> My first reaction here was: of course, good point! But then, on reflection, what properties should behave this way? Can you give an example of a property that makes sense to override in internal subclasses but not in external subclasses, but that must be accessible publicly?
>  

Well, boilerplate is boilerplate. I can imagine a number of situations where you’d need it — any time where you can some sort of logical division in your class design, where some functionality relies on internal invariants that are no business of the user while functionality is tweakable. At the same time, after thinking about it for a while, I agree that such cases might be rare:

1. If your class requires a lot of sealed members, then probably there is a better design somewhere that splits that class in multiple components. 
2. If your members are overriden internally but sealed publicly, the performance argument seems to be diminished to me — the compiler still needs to do some sort of vtable dispatch if 
    the identity of the instance type is not known at compile-time. 
3. I did a quick rudimentary regex through AppKit headers looking for stuff like "((n't)|(not)).{1,15}override“ and its true that there seem to be only a few dozens of documented methods where the documentation explicitly warns agains overriding them.  I have no idea how reliable the headers are or what the documentation is generated from, but that appears to me to be quite strong evidence 
in support of Károly’s and others arguments. 

I still think that explicit open is a better design conceptually, as it requires one to grant per-declaration permission instead than per-declaration prohibition, but I agree that it might be a sub optional design from the practical standpoint because of low frequency of sealed members in practice. In retrospect, It might be indeed worth seriously considering making ‚open‘ a class-level annotation only. But then, there are good arguments for having an additional ‚sealed‘ keyword for the relatively rare case where we want to explicitly exclude a method/property from being overridable. 

T.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/1f7bbac2/attachment.html>