On 2016-07-18 09:17:43 +0000, David Hart via swift-evolution said:
On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution
<[email protected]> wrote:
On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution
<[email protected]> wrote:
> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution
<[email protected]> wrote:
>
>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution
<[email protected]> wrote:
>>
>> Is there a summary somewhere of the motivation for allowing methods
to be declared non-overridable within open classes?
[...]
Garth: I think it's implicit in the reasons to prevent subclassing. The
mere fact that a class allows subclassing doesn't necessarily mean that
every member in it is designed to be subclassed. Consider
`UIViewController`: It's obviously designed to be subclassed, and some
methods in it (such as `loadView`) are intended to be overridden, but
others (such as `loadViewIfNeeded`) are *not* intended to be overridden.
And [if UIViewController were to be written in Swift] there'd be a good
reason why `loadViewIfNeeded` and others of its ilk couldn't be final?
I don't know UIKit internals, but I could imagine loadViewIfNeeded be
overridden internally, if one knows the precise internal workings of
UIViewController. That would require open, to allow overriding
internally but not externally.
I thought about this aspect a little more. I think it's fair to say
that we're breaking new ground for language design here. Classes
limiting inheritance to a certain set of subclasses are nothing new
(I've written & used classes doing this in C++, Java and C#), but no
language that I know of allows limiting overrides of a specific public
member in such a way. I think we need a convincing rationale for making
this esoteric middle ground between final and open members the new
default.
The UIKit example above isn't convincing at all. It is already quite
easy to allow package-internal subclasses to configure the behavior of
loadViewIfNeeded without such a novel language feature. E.g., the UIKit
team can simply make loadViewIfNeeded call into a non-final but
internal method:
public open class UIViewController {
private var _view: UIView? = nil
public final func loadViewIfNeeded() {
internalLoadViewIfNeeded()
}
internal func internalLoadViewIfNeeded() { // overridable internally
if let view = _view { return }
loadView()
}
public open func loadView() {
// Load it from a nib or whatevs
}
}
I see no drawback to this pattern; it is quite clear and simple.
Therefore, in the interest of keeping the language free of needless
complexity, I suggest we change the proposal to remove the implicit
"sealed" level of public member overridability, and support only "open"
or "final" class members.
For members, "open" should mean the opposite of "final", with no levels
in between. Member-level openness should be entirely independent of
visibility; so it should be possible to say "internal open" to mean an
internally overridable member that's not at all visible outside the
module -- the same as today's default.
(Note that (on platforms with an Objective-C runtime) "dynamic"
provides a third level of flexibility for class members; I argue that
it should imply "open". So in order of increasing flexibility, we'd
have "final", "open" and "dynamic" members. This seems easy enough to
describe and understand.)
I also suggest that for now, we should make neither "final" nor "open"
nor "dynamic" the default for public members of open classes: we should
rather require class authors to explicity add one of these qualifiers
to all public member declarations. This way, we can defer the argument
for choosing a default to a later (additive) proposal, once we have
some experience with this setup. Non-public members can safely keep
defaulting to "internal open", like they do today.
--
Károly
@lorentey
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
