[swift-evolution] [Proposal] Sealed classes by default

[L. Mihalkovic]

Regards
LM
(From mobile)

On Jun 30, 2016, at 9:12 AM, John McCall <rjmccall at apple.com> wrote:

>> 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.  

The issue is that according to this year's very interesting talk on perf is that an app's startup time can get thrown over the limit by having to perform too much relocation during dylib loading. I doubt too many will actually pay attention (i just started a nodejs app a couple days ago and before it did anything, bringing in angular and a few other dependencies downloaded 168M in over 60 modules)

> 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.

I think that you r considering an already sophisticated developer to whom you attribute the thought of 'whats it gonna be to use my code'. compared to the real life i know. That said I spent some time thinking about your arguments and I guess i can live with sealed (

> 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,

I believe most devs are not able to accurately predict what their code does and will allow to do be done. Over the last 20 years i have usually seen the most creative solutions being found despite what the original library writers did, but it is just my personal exp. i would prefer a world without forking dependencies, but... 

But i think you best argument is that idiomatic swift should not rely on classes as much as other languages. So in the end, the applicability will become more limited as we learn to write better swift over time. I think you are right. :)

> 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.