[swift-evolution] [Proposal] Sealed classes by default
rjmccall at apple.com
Thu Jun 30 02:12:52 CDT 2016
> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Jun 29, 2016, at 12:05 PM, Michael Peternell <michael.peternell at gmx.at> wrote:
>>> I'm still unhappy about this "sealed by default" proposal. That really looks like premature optimization to me. Instead there should be some `sealed` keyword. Maybe it should be called `applepublic` :-p Everyone will understand!
>>> `sealed` classes should be a special optimization used by optimizing developers who ask for it. Don't make it an unwanted and un-asked-for default optimization. The people who care for optimization much will learn about `sealed` and be able to apply the concept in both cases. The people who don't care about performance will just be disappointed by the "implicitly sealed" behavior. And with this proposal, when I read `unsealed` I can never know: "did this developer intend me to be able to subclass this class? or did he just not want to restrict me unnecessarily?" The documenting aspect of `unsealed` is so small.
>>> And `sealed` is just an optimization; IMHO the magic of static dispatch lies in final classes or final methods. Sealing everything by default just marks many classes and methods as implicitly final (because it can be proven that they are not subclassed). I just don't think that all these theoretical performance improvements are really worth the trouble in practice.
>> I'm confused about why you think this is so much of a problem. Do you really anticipate writing so many Swift libraries with public classes?
> Look at some of the public libs on github for server side swift.. one recently claimed 50 modules and counting... I think swift is missing a level of containment below modules, and people are starting to make up for it by creating a flury of (1class+1protocol) modules, especially now that package manager makes it so trivial to create them. I think this is only the begining... and nodejs is there to show how insane it could become: remember the recent "trimleft" nightmare (1 module with 15 LOC including brackets used pervasively that suddenly disapears).
I'm not arguing that there aren't going to be a lot of libraries. We're all excited about the number of libraries. Libraries are great. I'm trying to understand whether the objections here — which only matter on library boundaries — are motivated by any concrete experience writing such libraries in Swift.
Michael's argument was that sealed-by-default will be a major problem for those libraries and their users. Let's suppose that there's a library with a public class, and it's sealed by default. We can conclude that the author has never once tried to subclass this class outside of their library, because if they had, they would have gotten a compiler error. Therefore, at best, if I hack the library to allow subclasses, I'm going to be doing something that has never once been tested and certainly was not considered when the class was written. It's pretty clear that this is not the developer's intent.
Likewise, it's not true that "the documenting aspect of `unsealed` is so small". Under sealed-by-default, the developer has to make a conscious, deliberate step to allow subclasses outside of their library. They clearly do intend for you to be able to subclass this class. It's actually the reverse situation where the user doesn't know how to interpret the code, because under unsealed-by-default, they can't know whether the class is really intended to be subclassed or whether they just forgot to add the restriction.
More information about the swift-evolution