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

[Goffredo Marocchi]

Sent from my iPhone

> On 23 Jul 2016, at 06:00, Wang LiMing via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 写道：
>> 
>> 
>> on Fri Jul 22 2016, Paul Cantrell <swift-evolution at swift.org> wrote:
>> 
>>>> On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution
>>>> <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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> 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/e8b80e10/attachment.html>