> On Jul 17, 2016, at 5:16 AM, Károly Lőrentey via swift-evolution > <swift-evolution@swift.org> wrote: >> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> The second review of "SE-0117: Default classes to be non-subclassable >> publicly" begins now and runs through July 22. 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? > > +1, with notes: > > 1. The interaction of open with the dynamic keyword should be specified. Does > "public dynamic" imply “open”? Dynamic provides a level of flexibility beyond > mere subclassing, so I believe it should. Dynamic already conflicts with > “final”, so there is precedent for this kind of interaction in the language. > Note that “public dynamic” implying “open” means that we can’t have public > dynamic members in a public class that’s not also open. I think this > restriction is reasonable.
Right. I think the right way of thinking about "dynamic" is as a fourth member of this category of polymorphism control modifiers: "dynamic", "open", nonopen (currently unspellable in the proposal), and "final". Depending on where we ultimately go with "dynamic", it's *possible* that we'll want the ability to say "this method can be dynamically changed in-place but not overridden", but... frankly, I doubt we'll do that, and even if we do, it doesn't seem like the right default for "dynamic" alone (possibly "dynamic final"). So I think the answer is that "dynamic" permits overriding. > 2. What about @objc methods? The docs say that it makes a name available but > doesn’t guarantee dynamic dispatch on its own; so, it looks mostly irrelevant > to this proposal. Correct. @objc just means the method is usable from Objective-C. > 3. The problem of code migration should be addressed. For example, we might > want the auto-translator to automatically add open to non-final public > methods/properties in existing code, to make it less painful to upgrade. > People who simply accept the conversion results will get stuck with > un-audited open stuff all over their public APIs, which is not ideal. On the > other hand, this is no different to how their existing code behaved in Swift > 2, so perhaps it is the best choice. That's a good question. My intuition is that the philosophy of this change suggests that we should leave existing public classes non-open. > 4. I don’t have a strong opinion on whether “open" should imply “public". If > we accept that “public dynamic” is a stronger promise than “public open", > then it would look strange that the former requires public, while the latter > doesn’t. On the other hand, “public open” is going to be much more frequently > used than “public dynamic”, so arguably it deserves special treatment. > > 5. I was suprised by the restriction that the superclass of open classes must > also be open. But I don’t have a convincing usecase against it, so I guess > it’s fine. I like that we have the option to revisit this later. Right. It's fully source-compatible to allow this later. John. > > > For fun, here are the distinct combinations of access levels and dispatch > clauses for members in a "public open" class after this proposal: > > public dynamic // plus “public dynamic open” if we keep it separate. > [public] open // assuming “open” implies “public" > public > public final > [internal] dynamic > [internal] > [internal] final > private dynamic > private > private final > > >> * Is the problem being addressed significant enough to warrant a change >> to Swift? > Absolutely. >> * Does this proposal fit well with the feel and direction of Swift? > Yep. >> * If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > “Don’t use public subclassing" has been my policy for years, but I have not > had the pleasure to use a language that helps me enforce this. >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? > In-depth study broken across many short sessions. > > -- > Karoly > @lorentey > _______________________________________________ > 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
