Regards LM (From mobile)
> On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
