[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly
Chris Lattner
clattner at apple.com
Fri Jul 15 01:26:40 CDT 2016
> On Jul 14, 2016, at 10:58 PM, Charles Srstka <cocoadev at charlessoft.com> wrote:
>
>> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/862f83c1/attachment.html>
More information about the swift-evolution
mailing list