I think a lot of people in this thread are conflating "final by default" or 
"sealed by default" with "sealed everywhere". No matter what the default is, 
the frameworks aren't going to suddenly rewrite themselves in Swift with final 
everything; Objective-C will still be what it is. Furthermore, we're only 
talking about language defaults; we're not taking away the ability for 
frameworks to make their classes publicly subclassable or dynamically 
overrideable. That's a policy decision for framework authors to make. The goal 
of "sealed by default" is to make sure the language doesn't make promises on 
the developer's behalf that they weren't ready to keep. ObjC's flexibility is 
valuable, and Apple definitely takes advantage of it internally all over place; 
Apple also has an army of compatibility engineers to make sure framework 
changes work well with existing software. Not every developer can afford that 
maintenance burden/flexibility tradeoff, though, so that flexibility is 
something you ought to opt in to. You can always safely add public 
subclassability and dynamic overrideability in new framework versions, but you 
can never take them back.

-Joe

> On Dec 7, 2015, at 11:12 AM, Javier Soto via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> This was brought up in a different thread about private by default. Creating 
> a new thread for this. Quoting Mathew from the other thread with a short 
> summary about the motivation behind this:
> 
> "It is not uncommon to have a need for a reference type without a need for 
> inheritance.  Superclasses should be intentionally designed to be subclasses 
> and the author required to opt-in to subclassing and member overrides where 
> that is required by the design."
> -- 
> Javier Soto  _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to