Regards (From mobile)
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). > John. > >> >> -Michael >> >>> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution >>> <[email protected]>: >>> >>> How about `public(extensible)` ? >>> >>> On 29.06.2016 21:32, John McCall via swift-evolution wrote: >>>>> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution >>>>> <[email protected]> wrote: >>>>> Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't >>>>> really make sense. `internal` declarations are always sealed. >>>> >>>> Right. >>>> >>>> If "sealed" is the default behavior for public classes and methods — and I >>>> don't think the modifier is worth adding unless it's the default — then we >>>> need a way of "unsealing" classes and methods that's fairly pithy. I >>>> don't think a parenthesized spelling is good enough for that. And we >>>> should try to make the positive form ("can be overridden") shorter than >>>> the negative ("cannot be overridden"), because the latter will not usually >>>> be written. >>>> >>>> To me, the ideal spelling would be usable in place of "public". If it >>>> does have to be stacked with "public", then I think it ought to be pretty >>>> short. >>>> >>>> "communal"? :) >>>> >>>> "open" doesn't carry quite the right meaning, and it would need to be >>>> paired with "public", I think. >>>> >>>> John. >>>> >>>> >>>>> >>>>> -Michael >>>>> >>>>>> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution >>>>>> <[email protected]>: >>>>>> >>>>>> Do we really need a new keyword? Since we already have syntax like >>>>>> `internal(set)` couldn't we do `internal(unsealed)`, etc. >>>>>> >>>>>>> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution >>>>>>> <[email protected]> wrote: >>>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >>>>>>>> <[email protected]>: >>>>>>>> >>>>>>>> +1 for the concept of a "sealed” class. >>>>>>>> -1 for making it default. >>>>>>> >>>>>>> Aren't sealed classes already implemented? I think the keyword is >>>>>>> `final`.. >>>>>>> So there is nothing left to do :) >>>>>> >>>>>> No, `final` doesn’t allow for any subclassing, but `sealed` allows for >>>>>> subclassing within your module (where you can presumably write more >>>>>> efficient code based on knowledge of each subclass). >>>>>> >>>>>> - Dave Sweeris >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
