> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic <[email protected]> > wrote: > > On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution > <[email protected]> wrote: > >>> On Jun 29, 2016, at 12:05 PM, Michael Peternell <[email protected]> >>> 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. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
