I have to admit I don’t get why there’s so much push back about the whole public/open debate. I understand that completely removing the possibility to declare internally subclassable but publicly closed classes (like it did) might be harmful, but I’m still convinced that this use-case isn’t worth the complexity introduced by an additional access level modifier. This proposal offers a great compromise in that regards.
I think everybody agrees (at the very least to some degree) that the current access level system is too complicated. I also think that everybody agrees that the main reason behind that is the current set of keywords, or more specifically their spelling and/or semantics. This proposal does a great job at reducing this set to the ones that are in my opinion the most easily understandable: public, private and internal. The two former are generally well understood, and easy to explain to novices. The latter is in practice never written, but is also quite easy to teach later, for the sake of completeness. On the contrary, open feels like an odd exception, only applicable to a subset of the language entities, for a use-case that *does* happen but *isn’t* the norm. Why are we fighting so hard to keep it. SE-0117 states that designing classes for subclassing requires more care, but that’s also true *within* a library. Just because a library writer is able to put public in front of his/her class doesn’t mean the complexity to design it properly for subclassing goes away. If we really wanted to label Swift's sublcassing system “safe by default”, we’d have to make classes *final* by default (then we’d drop final and change open so it'd remove the default restriction). Instead, we have a solution that enforces a concept externally, but doesn’t do the same internally. We should choose a direction and commit to it. SE-0117 didn’t do that fully, this proposal does (but in another direction). Is one direction better that the other? Now *that* is debatable. But people generally understand classes to be subclassable, and it is also generally understood that this ability can be denied when classes are marked final. That’s the case in C++, Java, C# or Scala to cite few other languages. I couldn’t agree more that we shouldn’t adopt a design just because language X also does, but here we’re talking about the whole OO paradigm and its general understanding. The current behaviour (for publicly exposed classes) goes against this general understanding, which I think is harmful. I personally have no problem with putting the burden on the application writer, first because I find it is unrealistic to think that nothing can ever be used improperly when importing a framework, second because I think that experimented users should be able to find workarounds to use a library that may not have foreseen all possible corner cases. People might very well disagree on that, and I’d accept their position **if** they also stand on the “final by default” side. In either case, one keyword has to be eliminated (open or final). _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
