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

[L. Mihalkovic]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 5:24 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 28, 2016, at 10:17 AM, Mark Lacey via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>>> On Jun 28, 2016, at 7:55 AM, Sean Heber <sean at fifthace.com> wrote:
>>>> 
>>>>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> -1 for the fact that if all devs can write working code, fewer can do it in a clear structured fashion that is well designed for extensibility.
>>>> 
>>>> This sounds more like an argument for having sealed classes than not. As the proposal points out in the motivation, if the base class is not designed with subclassing in mind then overriding methods can result in unintended behavior (e.g. crashing, or other bugs).
>>> 
>>> But I think the counter argument is, what if you need to fix or workaround unintended behavior of the class you’re trying to use?
>> 
>> Sure, I understand that, and I don’t mean to trivialize that concern. I’m just pointing out that “code…that is [not] well designed for extensibility”, might not  work very well if you start using extension points that weren’t well thought through.
>> 
>> If you are designing for extensibility you’ll be carefully thinking about what should and should not be final both within and outside of your module.

We all think carefully about what we do... it just does not mean the same in regards to the outcome. It seems it is only in the software industry that we all think of ourselves as michelangelos or rubens.. unfortunately it takes a lot of errors to become humble about it.

>> Not doing so can result in bugs. This proposal introduces the ability to allow extension within the module but restrict it outside the module, and defaults to not allowing extension beyond the module.
>> 
>> You can argue both ways which default would be better, and I suspect people who mostly write libraries might opt for sealed-by-default, and people who mostly consume libraries might opt for open-by-default. My point is that open-by-default isn’t “better” because it allows you to potentially work around a problem in a base class, because by working around that problem by overriding a method that wasn’t designed to be overridden you don’t know how many other new problems you might be introducing (now or in the future if the implementation of the base class changes).
> 
> I think a good argument for sealed by default is that if we introduce `sealed` responsible library authors will already be marking all classes not intended for external subclassing as either `sealed` or `final` anyway.   The intended (and hopefully actual) public  API will be identical regardless of the default.  Making it the default avoids a lot of boilerplate keywords and makes ensure the API contract is stated more explicitly.
> 
> The only case where the default should make a difference is when a library is written without consideration of subclasses.  As you point out, in that case it is a really bad idea to attempt to work around a bug with a subclass.
> 
>> 
>> Mark
>> 
>> _______________________________________________
>> 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