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 > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
