> 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. 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. 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. 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. 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
