> On Jul 21, 2016, at 3:13 AM, Tino Heth via swift-evolution > <[email protected]> wrote: > > >> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution >> <[email protected]>: >> >> A class that is closed in 1.0 can be opened in 1.1; a class that is `final` >> in 1.0 *cannot* be opened in 1.1 (or at least it's a breaking change if it >> is). > Wait a moment: Aren't "closed", "sealed" and "final" basically all the same > as soon as you cross module borders? (but I guess it's just that some words > are in wrong order…)
Not at all - `closed` and `sealed` are two different names proposed for the same thing but `final` is very different. If you are using a `final` type from a library you (and the compiler) know all variables of that type reference instances of *exactly* that type. You do not get that guarantee with `closed` / `sealed`. In that case a variable may reference a subclass defined in the same module as the type of the variable. The similarity is that outside the defining module you cannot subclass `final` or `closed` types. But the rest of the semantics are quite different. > > But anyways, the imho important part is between the parenthesis: > Of course you can rename public properties, mark methods as final, rename all > your classes or delete the repository of your library easily. > It might break other peoples code and make them angry, but if this is the > driving motivation for SE-0117, the whole proposal is a paradox: > Changing the default for subclassability will break other peoples code on a > gigantic scale — not only single methods or classes, but nearly every > framework. > > Just imagine this fear of breaking changes had been applied to Swift… do you > think it would have been better for the progress of the language? > I don't think so, and I think that libraries aren't that different in this > aspect: > When you start something new, you want breaking changes happen as soon as > possible, when there is the most tolerance for them. > > As I keep saying for a long time, I think that attitude is an aspect that is > terribly neglected here, and imho there are already enough established > languages which are pulled down by fear of breaking changes. > Although I have problems sorting out what "swifty" actually means, I might > have a longer history as an Apple-customer than most other discussants here, > and all marketing aside, there is one distinguishing principle that can be > illustrated with many examples: > Better products are preferable over stable products. > > - 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
