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

[Vladimir.S]

On 29.06.2016 22:05, Michael Peternell 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!

I understand your point of view. But I also think about the proposal as 
forcing the developer of public(! i.e. usually which exported from some 
framework) to carefully think if he/she really wants to allow exported 
types will be extensible. Not just about performance.

And as was mentioned, 'sealed' is not 'final' : you can extend the sealed 
type in internal scope, but it will be final for public scope. (If I don't 
miss something)

But, yes, I'm also not sure if we should seal by default and not introduce 
`public(final)` or `public(sealed)` access modifier for those who 
explicitly don't want to allow extension of exported class.

>
> `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.
>
> -Michael
>
>> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution
>> <swift-evolution at swift.org>:
>>
>> 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 <swift-evolution at swift.org> 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
>>>>> <swift-evolution at swift.org>:
>>>>>
>>>>> 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 <swift-evolution at swift.org> wrote:
>>>>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell
>>>>>> <michael.peternell at gmx.at> wrote:
>>>>>>
>>>>>>
>>>>>>> Am 29.06.2016 um 15:54 schrieb David Sweeris via
>>>>>>> swift-evolution <swift-evolution at swift.org>:
>>>>>>>
>>>>>>> +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 swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>> _______________________________________________ swift-evolution
>>>>> mailing list swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________ swift-evolution
>>>> mailing list swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________ swift-evolution
>>> mailing list swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________ swift-evolution
>> mailing list swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>