There’s two case : 1. Bug from customer’s code 2. Bug from library/Framwork’s code
If we fix the case 1(forbidden subclass/overriding), means the library/framework’s author must fix case 2 If want customer fix the case 2(allow subclass/overriding), means we can’t fix the case 1 What’s our target? case 1 or case 2? Case 1 depends on the decision of case 2(customer fix or author fix) It’s big problem that can’t solved by language features. I think our target should be a language with better features that can improve the quality of code/product. 在 2016年7月23日，上午2:39，Dave Abrahams via swift-evolution <[email protected]<mailto:[email protected]>> 写道： on Fri Jul 22 2016, Paul Cantrell <[email protected]<mailto:[email protected]>> wrote: On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution <[email protected]<mailto:[email protected]>> wrote: I wrote that subclassability is not an important element of safety **independent of overriding**. If you don't allow any overriding, your code is always “resilient” enough to handle subclassing. Code can make assumptions about a type having a fixed set of subclasses known at compile time: switch foo { case is YinFoo: ... case is YangFoo: ... default: fatalError("only two kinds of Foo known") } Granted, code like this is usually a sign of a flawed design. Reasonable uses for the “fixed, known set of subtypes” pattern are rare. Design quality questions aside, however, it is not strictly true that preventing all member overrides guarantees that code is resilient to unexpected subclassing. Point taken. -- Dave _______________________________________________ swift-evolution mailing list [email protected]<mailto:[email protected]> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
