> Chris Lattner wrote: > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > > * What is your evaluation of the proposal?
+0.9. I'm positive with making the subclassability of exported classes explicit, but I'd reconsider the keywords proposed. Given how the ecosystem has shaped up so far, there are very few cases where Swift classes could be realistically patched by subclassing and overriding. Instead, forking and recontributing open-source code is the better way to go. From my OOP in any programming languages, almost all unplanned (by library author) uses of subclassing have become terrible hacks that were hard to maintain in application code. And I don't want to imagine having to maintain a library that multiple users have patched by subclassing without a documentation of the contract between the superclass and its subclasses. In Swift, classes seem to be most essentially about reference semantics and not so much about inheritance. With that, I think it's better that unlimited subclassing becomes a conscious choice by the library author, so that we also increase the probability of remembering to document what can be overridden and how. Originally, I would've even supported making `final` the default, but adding the new "sealed" inheritance mode is a very good compromise that makes life easier when writing application code. Sealed classes also open a new language design opportunity where `switch` cases can be proven total given a sealed class type as argument. However, I also think we shouldn't merge the the `public` modifier with the newly proposed keywords. From the alternatives mentioned so far, I'd give my +1 to `public open class/func` or the spelling `public(open) class`. In this position, I think it'll be unambiguous given context whether `open` acts as a keyword or not. Alternatively, we could reuse the `super` keyword in this context; the only minor issue I can see in `public super class` (besides that "superclass" should be written without a space) is that public unsealed classes aren't the only publicly visible superclasses (sealed classes are also publicly superclasses of their public subclasses). Well, and that the "superfunc" in `public super func` would be an unfamiliar term, even if it's easily taught as the kind of function which you should consider calling as `super.foo(...)` somewhere in an override. The proposal also left open whether the subclassability is inherited in subclasses. I think it's clear that the answer is "no", and thus every subclass of a publicly subclassable superclass is only publicly subclassable if explicitly marked so. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes, Swift should use language design opportunities like this to statically encourage thoughtful library design. > * Does this proposal fit well with the feel and direction of Swift? Yes. It also doesn't take away the option yo make well-thought use of OOP better in the future, such as abstract classes. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? N/A. > * How much effort did you put into your review? A glance, a quick reading, > or an in-depth study? Quick reading or a bit more. — Pyry _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
