On Jul 15, 2016, at 9:36 AM, L. Mihalkovic <[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). >> >> 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. > > I think seeing it as 'clear' is pure perspective, rather than fact. For > instance it might ba apple's perspective, but not red hat's (consider that it > took 10 years to be able to delete apps from our devices... indicating that > from apple's view point there seems to be a mindset that we cannot do things > opportunistically, assuming the consequences of our choices, which does exist > in others parts of the technology planet).
I think you’re missing my point: if a framework vendor fails to anticipate some use-case, and the affected part of their API is defined in terms of structs and enums, then subclassability is immaterial. Allowing unanticipated subclassability could address some slice of the problem, but it is “clearly” not a general solution to problem of an API vendor providing an insufficient API. Also keep in mind that many other things in Swift (e.g. methods not being public by default, not being “dynamic” by default) already cut across this. All of this means that while the experiences using Objective-C frameworks can and should inform this discussion, but it does not translate “directly" to Swift. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
