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

[Andre]

2016/07/19 16:43、Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> のメッセージ:

>> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Denial of subclassing has always been opt-in in ever other language I’ve used (C++ and Java, to name two, and Objective-C (and older C++) don’t even have that much). Sealing a class against subclassing is one thing, but not providing any kind of escape hatch, any kind of IUnderstandThatSubclassingMayCauseSunsToGoNovaOrGalaxiesToExplode marker, hamstrings all users of the code. Opt-in sealing at least constrains this scenario to places where the framework writer thought it was worth adding the extra protection against horrible horribleness.
> 
> You know, one thing I haven't seen mentioned is that, just as sealed-by-default preserves the options of library programmers, it also preserves the options of the language itself.
> 
> Suppose the people who think this is a huge mistake are correct, and we ultimately conclude that sealed-by-default is a disaster. What can we do about it? Well, we change Swift 3+n to open all classes by default. This would be source- and binary-compatible with all existing code; the only wrinkle is that classes compiled with a sealed-by-default compiler would still be sealed. (And that's not even a problem yet, since stable ABIs are not a thing yet.)
This is exactly my thought as well, if it does end up not optimal it can always be changed back in a subsequent update.

> The reverse, however, is *not* true. Going from open-by-default to sealed-by-default is source- and binary-incompatible. If we don't do it now, we may never be able to do it.
> 
> That means this is our one chance to try this. The outcome is uncertain; there are good arguments that it will improve things, but there are also good arguments that it will make things worse. But if we're afraid to try this now, we'll never be able to try it again, and we won't know if it would have worked. Whereas if we *do* try it now, we can always roll it back later.
I got the feeling that's why this is being pushed now and not swift 3.1 or 4...

> Software quality is one of the biggest problems our profession faces. We handle crushing amounts of complexity, teetering towers of abstraction, intertwined code that's at the ragged edge of our ability to comprehend it. Quite possibly the most urgent need in our industry is tools to help us manage it.
This is implicitly the reason that I changed my +0 to +1, alot of software is crap and it's crap because we don't get a handle on complexity, and this has a potential to reign some things in and bring a little discipline where it's needed.

I was originally very very against this, but as I thought about it I realized my only "real" reason at the end of the day was fear: fear of loosing certain flexibility, fear of loosing a tool I have used in the past, fear of change (again only speaking for myself) ... and really what I'm getting in return for that change though is the potential for some real increase in reliability (and maybe a lot of performance) on all sides. 

Things really teeter out of control I think because we can do all this crazy stuff behind the back of everything else and while this gives great flexibility to do some truly remarkable things,  it also piles up on top of itself and mucks things up... it works until it doesn't... and while the objc world is much more disciplined than others, my experience in the PHP/JavaScript side of things makes me never want to go back to that place... infinite regresses into over-complexity... 

> Sealed-by-default might turn out to be a powerful tool for managing complexity, helping us prevent unexpected interactions between the implementation details of separate modules. Or it might not. But we ought to find out. If we always take the conservative option, if we always stick to the tried and true, we will never advance the state of the art, never find solutions to the problems that make "all software sucks" a truism.
Agreed, and I'm ironically reminded of the old days (as a barely conscious human being) where everyone was poopooing objective-c and why don't we just stick to codewarrior and metrowerks and c++... new is bad and what we had is just fine, interface builder is weird, oh and those square brackets what are those etc etc... I'm not saying this is the same thing or that arguments against this proposal are not merited (of course they're merited) but it's a trade off and I think what we would get in return would be huge and potentially more useful in the long run. (wow have i come full circle...)

Maybe we do need to be able to unscrew the bottle and be able to override something forcefully as a last resort and maybe I should have not voted a full +1 because I agree with others that it's an important function... but in any case I think we should take a deep breath and long term think about what is really trying to be accomplished.... 

> We need to be bold and take a chance. If it doesn't work out, we can undo it. But if it does work out, we'll be better for it.
+1000 yes

Andre

> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> 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/20160719/a75dd349/attachment.html>