[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall

[Haravikk]

> On 16 Feb 2016, at 22:43, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Florian,
> 
> I have always taken care of this problem in other languages without recurring to specialized language features.  For example:
> 
> class Foo {
>     func _someMethod() {
> 	// Do something important
> 	…
> 
> 	// Now give subclassers a chance to do something
> 	someMethod()
>     }
> 
>     func someMethod() {
> 	// Default does nothing
>     }
> }
> 
> This way you are in control when someone else overrides someMethod since _someMethod() does the important stuff first and then calls someMethod() to allow those extending the class to do something. 
> 
> Also, I can modify _someMethod() and move the “Do something important” part to be after the call to someMethod().  

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.

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/d3bf6466/attachment.html>