[swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[John McCall]

> On Jul 17, 2016, at 5:16 AM, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:
>> On 2016-07-16, at 07:52, Chris Lattner via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution