[swift-evolution] Final by default for classes and methods
Andrey Tarantsov
andrey at tarantsov.com
Sun Dec 20 15:17:52 CST 2015
This is another proposal that's right on principle, but breaks down in real-world scenarios.
> To play devils advocate, take for example UINavigationController in UIKit on iOS.
This.
Real iOS apps subclass and override things that were never supposed to be overridden, swizzle iOS internals and do a lot of other nasty stuff, because sometimes that's the only way to get the effect you want, and you get to test betas of future iOS releases anyway, so if something breaks, you'll catch it and release a fix.
I'm really worried about the world where monkey-patching iOS internals is no longer possible. Thankfully, a Swift-based UIKit isn't anywhere on the horizon.
ON THE OTHER HAND, I do agree with this proposal for our own code. I've always used
// override point
to mark methods designed to be overridden, and a keyword to document this formally would be appreciated.
A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/76fe7cd1/attachment.html>
More information about the swift-evolution
mailing list