
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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; float: none; display: inline !important;" class="">“this method is private but overridable,”</span></div></blockquote></div>+1 ;-)<div class=""><br class=""></div><div class="">It would make the language more orthogonal — but I'm afraid this option died when "open" was added, and I have to admit that it would make things complicated as well:<div class="">Methods that shouldn't be called directly (like UIView.draw and layoutSubviews) might require calls to super, and I don't expect that the recently pitched proposal for "typeprivate" will reach the review phase.</div></div><div class=""><br class=""></div><div class="">If the patterns discussed are generally considered to be a bad fit for Swift and merely legacy, instead of changing the language itself it could be feasible to tinker with the tools instead:</div><div class="">- Smart autocompletion could hide methods that shouldn't be called (and place didDeselectRowAtIndexPath at a less prominent position than the more important didSelectRowAtIndexPath ;-)</div><div class="">- The skeleton for an override could include a call to super if it is needed, which would save a whole bunch of keystrokes</div><div class=""><div class="">I think there is big potential in the fact that Swift is designed in the same company that builds the most important IDE for it, which could be leveraged with annotations that don't affect the compiler:</div></div><div class=""><br class=""></div></body></html>