<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I like your idea of @super() a lot :)!<br><br>Sent from my iPhone</div><div><br>On 15 Feb 2016, at 22:52, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">This is an interesting idea, and fits well with the theme of preventing mistakes in Swift, but I think that the proposed solution isn’t flexible enough, as there are cases for inheritance patterns where extending doesn’t actually make sense, so having to specify an exception every time could quickly become annoying.</div><div class=""><br class=""></div><div class="">I think the better solution is to instead allow super-classes to specify whether or not their method must be called when overridden/extended. For example:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class View {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>@super(required) func viewDidLoad() { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class Button : View {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>override func viewDidLoad() { … }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>class Widget : View {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>override func viewDidLoad() {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>super.viewDidLoad()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">In this extension of your example Button will cause an error because it overrides viewDidLoad() but fails to call the parent’s method as required by the @super attribute. However, Widget compiles successfully because it follows the requirement.</div><div class=""><br class=""></div><div class="">So the options for @super would be:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class=""><b class="">required: </b>child-class must call parent implementation of this method.</li><li class=""><b class="">optional:</b> default behaviour, child can choose whether to call the parent’s method.</li><li class=""><b class="">denied:</b> child may not call parent’s method (useful if it makes assumptions that a child-class may not follow), but can still extend/override.</li></ul><div class=""><br class=""></div></div><div class="">I think this would be a more flexible solution to the problem, and put the decision in the hands of those writing classes designed for inheritance. I’m not 100% sure of whether to rename override to extend, I like extend better personally, but it probably doesn’t matter overall.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Feb 2016, at 20:57, Florian Liefers via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hi!<br class=""><br class="">I would like to suggest to replace the override keyword for functions by something like extend and replace or to add an annotation like @SuppressSuperCall (don’t know a good name for it).<br class="">The reason for this is, that it might happen, that one forgets to call the super’s implementation in an overridden function or if one reads the code it might not be obvious why the super’s implementation is not called:<br class=""><br class="">class View {<br class=""> func viewDidLoad() {<br class=""> // does something<br class=""> }<br class="">}<br class=""><br class="">class Button: View {<br class=""> override func viewDidLoad() {<br class=""> super.viewDidLoad() // <— this might be forgotten<br class=""> // do something other<br class=""> }<br class="">}<br class=""><br class="">The compiler will accept if one overrides a superclass’s function but does not call the superclass’s implementation which is often ok. The developer should clearly state that he doesn’t want to call the superclass’s implementation, otherwise the compiler should throw an error.<br class=""><br class="">// Example for extending a function<br class="">class Button: View {<br class=""> extend func viewDidLoad() {<br class=""> super.viewDidLoad()<br class=""> // do something<br class=""> }<br class=""><br class=""> extend func viewDidAppear() {<br class=""> // do something<br class=""> } // <— the compiler should throw an error here.<br class="">}<br class=""><br class="">// Example for replacing a function<br class="">class Geometry {<br class=""> func volume() -> Double {<br class=""> return 0;<br class=""> }<br class="">}<br class=""><br class="">class Cube: Geometry {<br class=""> var length: Double = 0.0<br class=""> replace func volume() -> Double {<br class=""> let v = length * length * length<br class=""> return v<br class=""> }<br class="">}<br class=""><br class="">Cheers,<br class="">Florian<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>