keyword to force calling the super on any method

[Xample]

Today I faced the following code

class A {
 // silly warning comment: if you override this, don't forget to call the super method to avoid memory leaks
onExit() {
// do some important cleaning stuff
}
}

class B extends A {
onExit() {
super.onExit(); // good
}
}

class C extends A {
onExit() {
// forgot to call to super.onExit = memory leaks
}
}

The problem is that, unlike a constructor, there is no way to force a method overriding another one to call the parent "super" function.

I wished we had a "concrete"* keyword to let the user know he must call the super method.

class A {
concrete onExit() {
// do some cleaning stuff
}
}

class B extends A {
onExit() {
super.onExit(); // no error
}
}

class C extends A {
 // error: Declaration of derived method must contain a 'super' call
onExit() {
}
}

In another language, I could have used the final keyword to prevent overriding the method but then… no overriding allowed neither.

• "concrete" In opposition to "abstract" (for lack of a better name), other ideas: "important" or "mandatory"

Instead of requiring overriders to remember to call super, you could do a design like so:

class A {
    final exit() {
        // do some important cleaning stuff
    }

    /** Override me to your heart's content. */
    onExit() {}
}

class B extends A {
    exit() { /* forget to call super() */ } // Errt, not allowed, no overriding 'exit'

    onExit() { } // Write whatever you want, the important cleanup will be done in 'exit'
}

If we had #1534. Would that be sufficient for your use case?

[Xample]

“final” or “seal” (as in #1534) are not sufficient. I have no hand on who calls exit(). Imagine the angular 4’s “onDestroy” hook, if I want to make a baseComponent implementing the “onDestroy” and to extend this component, I must remember my parent’s to already have it’s onDestroy. The framework is calling the method, the interface is given by the framework, therefore I cannot rename it.

If you can't rename it, you presumably can't add the concrete modifier to it either?

[Xample]

The framework is giving you the interface. You would add concrete on the class implementation (not on the interface).

[jcalz]

A workaround: Declare that onExit() returns a "receipt" that proves it was run on the superclass, and make sure that the only (reasonable) way to get such a receipt is by calling super.onExit(). In the following case, ExitReceipt is a private static member of A: so methods of A can refer to the value A.Receipt, but methods of B and C cannot. And the type of A.ExitReceipt is an instance of an anonymous class with a private member, so you can't easily get a new one.

class A {  
  private static ExitReceipt = new (class {
    private property: string = "";
  })();

  onExit(): typeof A.ExitReceipt {
    // do some important cleaning stuff
    return A.ExitReceipt;
  }
}

class B extends A {
  onExit() {
    // do some before-cleanup stuff
    const exitReceipt = super.onExit();
    // do some after-cleanup stuff
    return exitReceipt;
  }
}
class C extends A {
  // doesn't work since it doesn't return a receipt  
  onExit() { 
  }
}

Does that make sense?

[RyanCavanaugh]

Which other languages that support OOP have this construct?

[Xample]

I found the @callsuper decorator in Java
https://developer.android.com/reference/android/support/annotation/CallSuper.html

usage

@CallSuper
  public abstract void onFocusLost();

From this initial question

But in this implementation (to my understanding), the @callsuper decorator forces the method to call "super". In my case, any subclass should implicitly inherit this @callsuper decorator. In their Java example, they ensure this behavior adding the abstract keyword.

[Xample]

@jcalz interesting hack but I don't have the hand on the interface, only the implementation

[jsamr]

@Xample I find the construct interesting, in that it enhances the contract between classes of the inheritance tree. I don't recall such a construct in other OO programing languages.

I think the keyword semantic should refer to some idea of nesting, since each descending class in the inheritance tree has to call the upper super method... Perhaps nested or onion. "mandatory" sounds like the implementation is mandatory (like "abstract") and "concrete" is weird in that the opposite of abstract would rather be "any defined method", which is orthogonal to this construct.

[Xample]

@sveinburne english not being my mother tongue, its hard for me to find a keyword which really sounds good. What I can think about is that the function should have a name referencing that it will always be called i.e. we cannot shadow this method. You want to call it "bright" ? or maybe "root" as you refer to a tree ?

[dardino]

I think your problem can be resolved with this:

class A {
  // this is private then is not overridable
  private onExit() {
    // do some important cleaning stuff
    // call overridable method empty in base class
    this.OnExit();
  }
  OnExit() { } // or abstract
}

class B extends A {
  OnExit() {
  }
}

}

[Xample]

@dardino it's a solution if it's your own code and you do not rely on interfaces. "onExit" being part of an interface it cannot be private. The real life use of my proposal is mostly for hooks. Like we see in angular or [ionic] (https://ionicframework.com/docs/nightly/api/navigation/NavController/#lifecycle-events) Lifecycle events (but not restricted to).

let's take the following example:

export class BaseComponent implements OnDestroy {
  ngOnDestroy() { 
 // clean up stuff
 }
}

where OnDestroy is as follow:

export interface OnDestroy {
    ngOnDestroy(): void;
}

now imagine I would extend this class

export class AClass extends BaseComponent {
  ngOnDestroy() { 
 // problem if I do not call the super ngOnDestroy() function
 }
}

A "mandatory" keyword would print an error if we forget to call the super method. (as it is already the case with constructors of class extending another one)