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