<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=""></div><div><blockquote type="cite" class=""><div class=""><div class="" 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;">1) Unless you know exactly what a subclass should do, you can not make assumptions about when a subclass should call its super implementation.</div></div></blockquote><div>afaics, the majority agrees on this</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;">2) I think it would be desirable if the default behavior is that a subclass is expected to call super in methods it overrides, not doing so should be a compile warning. This will be the general case, and I think it should be the default behavior.</div></div></blockquote><div>I've been a fan of this since the first "all methods should be final" debate (imho it's a good compromise), but now the situation is more complicated because of the the differentiation of same-module overrides vs. external subclasses (after all, this feature could be modelled as yet another access level: public < open < "replaceable")</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;">3) I think you should be able to silence that warning somehow. I am thinking something like:</div><div class="" 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;">override! func setFrame(...) { // note the ! at the end of override</div><div class="" 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;"> // not calling super</div><div class="" 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;">}</div></div></blockquote><div>That was my favourite for overriding of methods that are neither final nor open. Imho the link between the "!" and the omission of the super-call isn't that intuitive, but as it is reused in 5), I'd view it as a general indicator for "I know what I'm doing".</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;">4) There should be a macro / swift keyword that specifies that there is no need to call super. Something like @discardableFunc would be close to the existing @discardableResult annotation in Swift 3. This should be added to all functions where the default implementation is empty or unimportant etc.</div></div></blockquote>This is coupled with 2) — but imho there should be a name/keyword for each option, no matter which one is default, so that discussion can be split into two parts ("how should it be called?", "what should be default?")<br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;">5) There should be a macro / swift keyword that specifies that the subclass is not allowed to call the super implementation. @deposedFunc? A native English speaker can properly come up with a better name. There are a few cases where this is relevant; NSOperations start() function is not allowed to call super. Using this keyword should make it a warning to call super and again I imagine that should also be silenced by using override! in case you are forced to call super anyway for some reason.</div></div></blockquote></div>+1<div class=""><br class=""></div><div class="">Afaics, inheritance hasn't been covered yet, but the rules should be simple:</div><div class="">Making the call to super mandatory should always be possible, only the opposite would be problematic.</div><div class=""><br class=""></div><div class="">A full-fledged proposal imho should also include a paragraph about "interception":</div><div class="">override func foo(input: String) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super.foo(input + " bar")</div><div class="">}</div><div class=""><br class=""></div><div class="">override func bar() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if condition {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super.bar()</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">I wouldn't want to forbid either case, but they add a small amount of danger (compared to neutral monitoring), so it should be justified.</div><div class=""><br class=""></div><div class="">- Tino</div></body></html>