[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic]

Regards
LM
(From mobile)

> On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> If you have a ParentClass and a SubClass, and the ParentClass is sealed while the SubClass is subclassable. What happens? No matter how this question is answered, I don't like the answer. (compile error => bad. || make it as the user wishes => bad; what do we gain by letting ParentClass remain sealed? || make ParentClass implicitly subclassable too => bad.)
> I'm happy that there are not only supporters for this proposal, but imho the example is no compelling argument:
> With no doubt, I'd expect I can subclass only SubClass — like I can't instantiate an abstract class, which is just fine for its children.
> ParentClass might do some dangerous things that don't happen in SubClass, so there might even be a use-case (but imho it would be better if I could mark ParentClass as internal in this situation).
> 
> But imho there is another aspect I haven't read about yet:
> "final by default" would have had direct impact on any developer, while this proposal merely changes things for those who create libraries…
> So, the question is: How will those be build?
> 
> If you live in a world of secrets and non-disclosure, I can understand that sealed is desirable — but that's not the future I want to see, and github is a good indication that others share this opinion.
> 
> If you share the sympathy for Open source, the two scenarios are as follows:
> We stick with "open by default"; users of libraries will use them in ways that the creator hasn't thought of before, and bugs will show up.
> But: We know how to deal with bugs, that's our job! So in the best case, we find the reason for the bad behavior, create a pull request, and everyone is happy.
> 
> With "sealed by default", the situation changes:
> Users are protected from some simple bugs, but nonetheless, they'll encounter situations where the library doesn't do exactly what they want.
> So, you take a look at the source, find the problem, and fix it.
> It's no bug at all, it's just a tiny degree of freedom that is missing because it wasn't important to the author.
> You can create a pull request as well, but it doesn't offer a real improvement to the author, who is already busy with dozens of similar requests by other users -> you end up with a custom branch with all the housekeeping associated with it.
> 
> So overall, I'm quite sure that the proposal won't improve software quality, but rather degrade it.

:) 

> Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution