> Am 21.07.2016 um 14:48 schrieb Tino Heth via swift-evolution > <[email protected]>: > > >> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution >> <[email protected]>: >> >> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
