> On Jul 2, 2016, at 10:58 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > > Regards > LM > (From mobile) > > On Jun 30, 2016, at 9:12 AM, John McCall <rjmcc...@apple.com > <mailto:rjmcc...@apple.com>> wrote: > >>> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> >>> wrote: >>> >>> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>>> On Jun 29, 2016, at 12:05 PM, Michael Peternell >>>>> <michael.petern...@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 referring to libraries as a tool for code organization. Right now, some of the build tooling around Swift assumes that libraries have to be built as a separate dynamic library, and I agree that that's really unfortunate. >> 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 ( Okay. I think this has been a really productive conversation, and it's definitely made the proposal better, thank you. John. > >> 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
