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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
