> On 20 Jul 2016, at 06:57, Jaden Geller <jaden.gel...@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
