[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Matthew Johnson matthew at anandabits.com
Fri Jul 8 16:26:58 CDT 2016


The stories I’ve seen about things Apple’s frameworks need to deal with are another.  I don’t have links handy but they shouldn’t be too hard to find for anyone interested in looking.

> On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> I've sent one I currently have myself. Look back on the thread posts.
> 
> L
> 
> 
> On 8 July 2016 at 18:14, Tino Heth via swift-evolution
> <swift-evolution at swift.org> wrote:
>> 
>> When was the last time you you thought "I really wish the author of that
>> library had restricted my options to use it"?
>> 
>> 
>> I really wish Objective-C had this feature from the start.  I believe there
>> would have been significant benefits to Apple's platforms and ecosystem.
>> The reasons for believing (or not believing) this have been discussed in
>> depth so there isn't a need to rehash them now.
>> 
>> I'm not asking for reasons but for a single persuasive example…
>> 
>> It is easy to claim that everything will be better if we add restrictions,
>> but so far, I haven't heard of any real problems cause by the current
>> defaults:
>> The motivation to change them is not because of actual experience, it's just
>> the trendy opinion that inheritance is evil.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 



More information about the swift-evolution mailing list