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

[Garth Snyder]

Károly demonstrated that it’s already possible to achieve the effect of a nonoverridable 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
> 	}
> }

Because the compiler understands “final” for vars, Károly's example works for them, too:

public class Argle {
    public final var value: Int {
        get { return internalGetValue() }
        set { internalSetValue(newValue) }
    }
    func internalGetValue() -> Int { return 1 }
    func internalSetValue(_ newValue: Int) {}
}

I agree that both of these forms are unsightly. If this were a common idiom, I don’t think it would be unreasonable to weaponize the compiler to make the setup cleaner.

Since we’re already living in a world that includes the possibility of (functionally) nonoverridable members, I would imagine there’s some probative value in assessing the codebases of current libraries. Is anyone aware of a library that uses such a form? I’m skeptical that library authors have demonstrated much interest in this kind of thing, but facts are friendly… 

Although loadViewIfNeeded() makes for an elegant code demo, I don’t really accept it as a motivating example for the need to make members non-overridable. I suspect it would be covered pretty well by the existing definition of “final”. There’s also no demonstrable harm to overriding it; the main argument seems to be that newcomers to UIKit might override it out of confusion.

Garth

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