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

[L. Mihalkovic]

Regards
(From mobile)

On Jul 18, 2016, at 7:12 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:

>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution <swift-evolution at swift.org> wrote:
>> I disagree that an `open` method overridden from a superclass is implicitly `open`.
>> 
>> As the rationale for the proposal states, overridability is hard to get right, and there is no guarantee that the consumer of an API is going to think about it. The default for override methods should not be `open` or `final`, it should be the internal equivalent.
>> 
>> A coder subclassing a public API, who themselves wants their subclass to be subclassable, should need to restate `open` where appropriate.
> 
> I don't think that defaulting to non-open would be a good idea.  Like I covered in the proposal, inherited open methods remain open; letting an override implicitly close off an open method would create a pretty unfortunate error-of-omission situation.
> 
> We could remove the default here and require the method to be explicitly open/nonopen/final, but then we really do pile up the modifiers:
> 
>  public open override func foo()
> 
> To me, the fact that it's already marked with "override" suggests the possibility of open-ness enough to remove the need to re-state it.  I can see why you might disagree, though.

the fact that someone thought that something could be extended does not imply that the one who extended it also carefully planed for her own code to be extensible... and even if one particular method A which was declared extensible has not been altered directly in a subclass, through extending others that are related and not having planned carefully the interplay, method A may have now been rendered unfit for further extension. 

So simply as a matter of following the logic of the proposal, every subsequent extension of something explicitely marked as open for subclassing should defacto be placed back into the default non-subclassable state, forcing the author to have to explicitely validate the new set of relationships existing between the methods in the subclass. Otherwise the logic does not hold, and the original proposal does not hold water: that which cannot be assumed as safe on level 0, cannot be suddenly assumed safe at level 1 of subclassing, because the outer API surface of level-n subclasing forms no more implicite guaranty of soundness than existed at level n-1. The proposal is all about the fact that it is the developer who MUST PROVIDE the soundness guaranty.


> 
> John.
> 
>> 
>> This also seems to be a general conflict in that you can always reduce the access, e.g. an API might have a `public open` method, but the subclass should be able to declare that as `override private` and thus the `open` keyword would be invalid in this context.
>> 
>> 
>> Scott
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution