
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">This is another proposal that's right on principle, but breaks down in real-world scenarios.<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">To play devils advocate, take for example UINavigationController in UIKit on iOS.</div></div></blockquote><div><br class=""></div>This.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>ON THE OTHER HAND, I do agree with this proposal for our own code. I've always used</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div>// override point</div></div></blockquote><div class=""><div><br class=""></div><div>to mark methods designed to be overridden, and a keyword to document this formally would be appreciated.</div><div><br class=""></div><div>A.</div><div><br class=""></div></div></body></html>