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

[Michael Peternell]

> Am 21.07.2016 um 14:48 schrieb Tino Heth via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution <swift-evolution at swift.org>:
>> 
>> Oops missed sending to the list.
> it's quite easy to hit the wrong button — but actually, the first recipient list was a better fit for the spirit of your motivation ;-)
> 
>> Swift 3 is going to break code - as you say - on gigantic scale already. All developers that switch to Swift 3 will have to upgrade all modules they have and any module developer will have to update their code for Swift 3. Does this potentially add additional work for a module developer? Yes (some will get hit harder then others)
> (hope there's at least general agreement on this…)
> 
>> but it will let them better reason and state their contract which can save effort longer term and improve maintainability.
>> Anyway this is about setting up a language and compiler supported way of allowing a module developer to more clearly state the API contract for their module while internally having greater freedom to design things as make sense. The defaults are being picked to favor being explicit about the contract which is a good thing for everyone.
> I had an intrinsic motivation for that reply — and this is not to stop SE-0117, which, after all, has already been accepted.
> Driven by the same motivation, I'm answering your message as well:
> How can you know that anything is "a good thing for everyone"? I can accept a decision that I consider wrong, but not that it is justified with false assumptions (or even lies — seen all that).
> There is a huge group of developers who think that the new defaults are no good thing, but absolutely terrible — and that is something supporters of SE-0117 have to accept, even if such tolerance doesn't fit into their mindset.
> I'm not even such a big fan of subclassing, but I wholeheartedly oppose this attitude of "we know what's best for everyone": If anyone had a proof that the decision is superior, he could have saved us a whole big discussion… but there is none, so as I advised to live with sealed-by-default, I advise the other camp to be happy about it and stop fortune-telling.

Hmm, I think the conflict is explained well here, it was a very insightful read for me:
http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html
http://martinfowler.com/bliki/EnablingAttitude.html
http://martinfowler.com/bliki/DirectingAttitude.html
(I think someone has already posted the link on this list, but I cannot find it right now.)

Interestingly, what I seem to share with Steve Jobs is his "enabling attitude" ;) This is also what I like about Objective-C, and the reason why I started making iPhone-apps at all. (In Swift there will never be something like RPC-mechanisms/NSConnection/KVO/NSProxy/Mocking-objects.) In case you are wondering: yes I use monkey patching occasionally.. about 2 times a year/5 hours per year; not that it is such a big deal, but it feels good to have this extra power when I really need it (which is rare, but it happens.) I just hope that Objective-C will stay for some time and that I can continue to use it, and that I'm not forced to write code in Swift 3+. Because that may be the time when I just leave the Apple ecosystem and look for another job ;) I feel like there is no point in fighting against SE-0117 anymore, because Swift already is too far away from what I want it to be, and one other step in the "wrong" or "right" direction doesn't really make much difference for me. Although I like value types: Objective-C + Swift-structs + private(statically-dispatched/not-accidentally-overridable)methods + Swift-enums = perfect language for me.

Bye bye Swift.

-Michael

> 
> Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution