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

[Alexey Demedetskiy]

From my point of view, ability to limit behavior in subclasses will do more harm than profit.
But several attributes can be applied.

1) default - override is enabled in any form. Current default behavior.
2) final - override is disabled in any form. Currently implemented.
3) stub - only override(instead) is allowed. This keyword should mark default bodies.

stub func renderShape(shape: Shape) { }

4) require - override(instead) is disabled. Call to parent is important to the object lifecycle.

This will introduce new keywords, and can be implemented separately from override(…) behavior.
Also instead of ‘stub’ ‘abstract’ can be used.

> Cc:swift-evolution at swift.org
> Subject:[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall
> Date:February 16, 2016 at 12:28:55 AM GMT+2
> 
> 
> +1 for what you outlined Alexey. I think maintaining the use of override as the keyword is the most understandable in the context and also is terminology usually used in various object languages. I like adding the optional qualifiers to allow (1) better diagnostics by the compiler, (2) clearer code, and (3) the opportunity for compiler generating the need coded (in a few of the situations).
> 
> Can something like this be used in the super classes interface definition to clarify expectations of a subclass?
> On Mon, Feb 15, 2016 at 2:07 PM Alexey Demedetskiy via swift-evolution<swift-evolution at swift.org(mailto:swift-evolution at swift.org)>wrote:
> > Hi
> > 
> > I would like to suggest you to extend your proposal.
> > 
> > In my practice, overriding super functions can have several semantics.
> > 1) Replace - simple case for abstract classes which implementation do nothing, or throw an exceptions.
> > 2) After super - things like viewDidLoad and viewWillAppear, setUp etc. All cases where super expect to be called before child code.
> > 3) Before super - opposite to 2.
> > 4) Override - no rules about order, but super call must be done.
> > 
> > So code can look like:
> > 
> > override(after) func viewDidLoad() {
> > // super.viewDidLoad()<— no need to call super at first line.
> > // child code
> > }
> > 
> > override(before) func tearDown() {
> > // clean code
> > // super… inserted by compiler
> > }
> > 
> > override(instead) func loadView() {
> > // super.loadView()<— marked as an error with appropriate fix-up to remove instead modifier
> > }
> > 
> > override func refillHealthBar() {
> > // absent call to super will cause an error with fix-up to add (instead) modifier
> > }
> > 
> > I am not sure about exposing this in a public interface and limit child override options.
> > 
> > But in general - what is your thoughts about this approach to problem that you mention?
> > 
> > 
> > >Hi!
> > >
> > >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).
> > >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:
> > >
> > >class View {
> > >func viewDidLoad() {
> > >// does something
> > >}
> > >}
> > >
> > >class Button: View {
> > >override func viewDidLoad() {
> > >super.viewDidLoad() //<— this might be forgotten
> > >// do something other
> > >}
> > >}
> > >
> > >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.
> > >
> > >// Example for extending a function
> > >class Button: View {
> > >extend func viewDidLoad() {
> > >super.viewDidLoad()
> > >// do something
> > >}
> > >
> > >extend func viewDidAppear() {
> > >// do something
> > >} //<— the compiler should throw an error here.
> > >}
> > >
> > >// Example for replacing a function
> > >class Geometry {
> > >func volume() ->Double {
> > >return 0;
> > >}
> > >}
> > >
> > >class Cube: Geometry {
> > >var length: Double = 0.0
> > >replace func volume() ->Double {
> > >let v = length * length * length
> > >return v
> > >}
> > >}
> > >
> > >Cheers,
> > >Florian
> > >
> > >
> > >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org(mailto:swift-evolution at swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
>