Is it more unreasonable to ask developers to seal their modules or users to unseal them? I would say Apple or third parties shipping frameworks could be asked to think about subclass ability before shipping their commercial library.
Sent from my iPhone > On 11 Jul 2016, at 07:36, Rod Brown via swift-evolution > <[email protected]> wrote: > > Resent for Swift Evolution: > > With the existence of Swift on the server, dynamically linked, independently > distributed frameworks will not be an Apple-only issue - this extends beyond > Apple's OS X-based platforms towards how dynamic frameworks link against each > other as if they are to be distributed separately. > > It is short sighted to suggest that all Swift deployments will be under > Apple's control. > > On 11 Jul. 2016, at 3:43 pm, Tino Heth <[email protected]> wrote: > >>> It is *not* the case with a framework. Dynamically linked frameworks can be >>> changed without the app even being changed. Imagine if Apple changed UIKit >>> and make UINavigationController final retroactively. >> Your argument is true, and you choose a good example — but it's actually the >> only one that exists at all: >> There are no other parties that ship frameworks that way, and I don't think >> this should change. >> >> So the benefits of this proposal would exist for Apple alone, and I can >> understand why sealed is convenient for an UIKit-engineer. >> It is tempting to aim for the easiest solution, but it is smarter to take >> the route that's better for the customer (and we happen to be the customers). >> And, as others pointed out before, Cupertino is free to diverge from the >> defaults in either direction, so it is only a little effort to have "sealed >> by default" without the bad side effects. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
