I have been following the discussion and reading the arguments in favor and against. I think I understand both sides better now.
If this proposal is accepted I hope some more thought is given to the naming. I would like to echo what others have said regarding the names. In particular I am still not sure about subclassable and overridable implying public. I think it would be more clear to to read "public subclassable class C". I have these thoughts regarding the naming: I think that subclassable could be implied when the class contains an overridable method or property. In other words, does it make sense to have an overridable method or property when the class is not subclassable? Oh, I just realized that it is more clear if it is expressed explicitly. It could also avoid making the mistake of making a class subclassable by accident. Also "subclassable class" sounds a bit redundant. In other words, I think subclassable implies it is a class. But I am not sure I would want to leave out the class part, which brings me to one of the other alternatives: public open class C public open func / var The pros here are that is is more concise. The public part could be left out because open seems to imply public. Open also suggests that it may be subclassable/ overridable. On the other hand subclassable/ overridable are both very clear though. Thanks > On Jul 9, 2016, at 12:29 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: >> >> >>> Of course it can be done either way. But there are significant ecosystem >>> robustness advantages to making sealed the default and comparatively few >>> downsides. Most libraries are open source (so can be modified directly or >>> via PR if necessary) >> First: >> The claim about robustness sounds like a fact, despite being just an opinion >> (feel free to correct me if you have any evidence at all). We should stay >> honest with our predictions. >> Second: >> Do you really believe there will be positive impact on open-source libraries? >> My forecast is that closed by default will dramatically increase trivial >> pull request where developers ask for unsealing so that they can do as they >> like… > > I think this is a good thing. It will force a considered answer and a > discussion about whether or not subclassing should be supported by the > library. > >> and I've no idea why somebody could come up with the idea that forking is >> desirable. > > Forking is desirable if your goals, needs, values, etc are substantially > different than the library author such that you do not agree on what the API > contract should look like. > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
