[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Wang LiMing]

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 <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> 写道：


on Fri Jul 22 2016, Paul Cantrell <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution
<swift-evolution at swift.org<mailto:swift-evolution at swift.org>> 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
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160723/8e5c1c70/attachment.html>