> On Jul 14, 2016, at 10:58 PM, Charles Srstka <[email protected]> wrote: > >> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> - Second is that clients of some other public API vended by a non-Apple >> framework (e.g. a SwiftPM package) may end up in a situation where the >> framework author didn’t consider subclass-ability, but the client desires >> it. In this situation, the core team feels that a bigger problem happened: >> the vendor of the framework did not completely consider the use cases of the >> framework. This might have happened due to the framework not using >> sufficient black box unit testing, a failure of the imagination of the >> designer in terms of use cases, or because they have a bug in their >> framework that needs unanticipated subclass-ability in order to “get a job >> done”. > > 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).
I’m not sure what you’re trying to say. I agree that it is clearly the case that a framework author cannot anticipate every single use case of their framework. However, it is just as clearly the case that “unanticipated subclassability” isn’t a general solution to that problem. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
