+1 to Brent’s reasoning. > On Jul 19, 2016, at 3:43 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Jul 18, 2016, at 11:04 PM, Gwynne Raskind via swift-evolution >> <[email protected]> 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.) > > 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. > > 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. > > 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. > > 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. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
