Sent from my iPhone > On 23 Jul 2016, at 06:00, Wang LiMing via swift-evolution > <[email protected]> wrote: > > > 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?
Beside input validation, proper use of failable initialisers, and exceptions... how and why would you target case 1 further as a library author practically? It sounds like something useful in some cases and noble in intention but also a bit of a slippery slope to patronising your users... you may as well write the whole code for then ;). Seriously though, what would your reasons be for case 1? > 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]> 写道： >> >> >> on Fri Jul 22 2016, Paul Cantrell <[email protected]> wrote: >> >>>> On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution >>>> <[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] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
