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

[Karl]

> On 20 Jul 2016, at 06:57, Jaden Geller <jaden.geller at gmail.com> wrote:
> 
> The keyword `open` would only be required to allow subclassing **outside** of the module. You will still be able to subclass inside the module as long as it isn’t marked as `final`.
> 
> This proposal wants classes to be `final`-by-default **outside** of the module and subclassable by default inside the module.
> 
> This is about making sure developers don’t accidentally release an API promising a more than they’re able to support. Once they decide that (a) a class won’t break when subclassed and (b) they’d like to support subclassing for that class until the next breaking change, they annotate the class with `open`.

Yeah, I very much do not support that. It creates additional complexity - all of these strange esoteric discussions we’re having about what should be, really, a pretty simple thing. I don’t want to have to remember all kinds of complicated rules what becomes ‘final’ and what becomes ‘open’ or what the defaults might be (if they’re not obvious) and how all of these other complex subclass rules apply. Just tag the things that can be subclassed - it’s all scoped to existing access scopes. Simple and easy to remember.

@Peter: Yes, final would be implied on all classes. You would be able to “open” them to remove that restriction, and it would be scoped to existing access scopes (as we do already for setter visibility). I.e.:

public internal(open) class MyAbstractBaseClass {

	// Contains some members which all fatalError()
}

private MySpecialisedClass : MyAbstractBaseClass { 

	// Specialised stuff here
}

Compare with the modifiers for class members:

public internal(set) myInternalVariable : Int32

Not only that, but it’s immediately clear by looking at MyAbstractBaseClass who is subclassing it. Compare with an implicit internal open and non-implicit public open (as in the proposal):

public class MyAbstractBaseClass {

	// Contains some members which all fatalError()
}

I think my suggestion improves local reasonability and simplifies the syntax requires considerably.

Like I said, I can’t see the reasoning behind limiting “open” to public classes. It’s just a concession to allow sloppiness inside of your own module, but even then - for complex internal classes with a mixture of overridable and non-overridable members, having to declare those “open” could even be of benefit. If it’s such a big problem, perhaps we can invent some kind of shorthand on the class attribute to declare all of its members overridable (like "open-all” or something).

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/fd50afe4/attachment.html>