<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Feb 2016, at 22:43, Ricardo Parada 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Florian,<div class=""><br class=""></div><div class="">I have always taken care of this problem in other languages without recurring to specialized language features. For example:</div><div class=""><br class=""></div><div class=""><font face="Consolas" size="2" class="">class Foo {</font></div><div class=""><font face="Consolas" size="2" class=""> func <font color="#942192" class="">_someMethod</font>() {</font></div><div class=""><font face="Consolas" size="2" color="#438139" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something important</font></div><div class=""><font face="Consolas" size="2" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</font></div><div class=""><font face="Consolas" size="2" class=""><br class=""></font></div><div class=""><font color="#438139" face="Consolas" size="2" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Now give subclassers a chance to do something</font></div><div class=""><font face="Consolas" size="2" class=""><span class="Apple-tab-span" style="white-space:pre"> </span><b class="">someMethod()</b></font></div><div class=""><font face="Consolas" size="2" class=""> }</font></div><div class=""><font face="Consolas" size="2" class=""><br class=""></font></div><div class=""><font face="Consolas" size="2" class=""> func <b class="">someMethod()</b> {</font></div><div class=""><font color="#438139" face="Consolas" size="2" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Default does nothing</font></div><div class=""><font face="Consolas" size="2" class=""> }</font></div><div class=""><font face="Consolas" size="2" class="">}</font></div><div class=""><br class=""></div><div class="">This way you are in control when someone else overrides someMethod since <font color="#942192" face="Consolas" size="2" class="">_someMethod</font>() does the important stuff first and then calls someMethod() to allow those extending the class to do something. </div><div class=""><br class=""></div><div class="">Also, I can modify <font color="#942192" face="Consolas" size="2" class="">_someMethod() </font>and move the <font color="#438139" face="Consolas" size="2" class="">“Do something important”</font> part to be after the call to <font face="Consolas" size="2" class=""><b class="">someMethod()</b></font>. </div></div></div></blockquote><br class=""></div><div>Is that the correct way around? I would have thought that _someMethod() would be the no-op that sub-classes can override? In languages where I’ve done this I would usually use doSomeMethod() but whatever.</div><div><br class=""></div><div><div class="">While it’s a valid design pattern, it doesn’t really work in Swift due to the lack of a protected (sub-classes only) visibility type.</div><div class="">Even if we did have protected visibility, the other problem is that you still have a single function to override, so what happens when you want a second level of extension? Either the child method has to hope that further sub-classes don’t mess it up, or they have to mark it as final and declare their own new child method for each level below them. Aside from being a fun thing to find names for, it could get messy very quickly, it’d be much cleaner supported by a language feature, and could actually be more explicitly defined as well.</div></div></body></html>