[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

Taras Zakharko taras.zakharko at uzh.ch
Fri Jul 15 02:52:15 CDT 2016

I have deliberately kept away from the discussion on this topic, as I didn’t feel like I can contribute in any meaningful way. In all honesty, I have barely used ‚traditional’ OOP paradigms in the last few years at all. While OOP is a useful tool and its great for modelling certain relationship and problems, I agree with the sentiment expressed by the core team that ‚open by default‘ OOP introduces a great deal of complexity for the framework creator, framework client and the compiler alike. Objective-C, with its dynamic message dispatch is a great example of a feature that is very flexible and quite beautiful, but at the same time so inherently unsafe, that it can easily be abused - AND that has been abused extensively. 

The fact is, the programming languages we are using currently don’t do a very good job in declaring, describing and enforcing invariants/contracts. More often than not, the invariants are expressed informally (if they are expressed at all). Under such circumstances, more openness means more chance to break things long-term. Until a more general solution can be found (API access roles? state invariants declarations?) anything that makes things more explicit is a good thing in my book. 

> On 15 Jul 2016, at 07:58, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> Or because the framework was developed in the real world, rather than Elysium, and real-world framework developers just about *never* anticipate every single way someone might use their framework (Indeed, if developers were capable of such a thing, there would be no need for third-party software in the first place).

If I am selling a frying pen, I am really not interested in people using it as a hammer ;) To be honest, I don’t really understand your post. A framework has a particular application domain and caters to certain use cases. It either meets its design goals or not. What does it have to do with need for third-party software? And how does ability to subclass makes it any better? 

— T

More information about the swift-evolution mailing list