Ensure/skip super call

[ncannasse]

In some code architecture, it is necessary for things to work correctly to always call the super method when you override it, and it can causes several issues when it's forgotten by some devs. Given this is general programming feature not specific to a given app or framework, I propose we introduce a @:callSuper metadata at the compiler level to enforce this.

class A {
     @:callSuper function init() { }
}
class B extends A {
     override function init() {
         // error super.init() was not called
     }
}
class C extends A {
    var initDone:Bool;
    override function init() {
         if( initDone ) return;
         trace("initializing");
         initDone = true;
         super.init();
        // we do not check all code paths to allow such patterns 
    }
}

[Simn]

Hmm... I don't hate it, but it seems a bit half-assed if it ignores control flow like that. Simply checking for the super.call() to exist in the syntax does not seem like much of an ensurance.

[ncannasse]

We could check that it's called in all code paths. But that would be more costly in terms of computation, and provide only theorical gain has I haven't yet hit into this actual issue. It might even be intentional (for exemple having a if( !isOwnedByMe ) return; before the super.init()). What we want here is to make sure the super call is not accidentally forgotten.

[Simn]

Yes I acknowledge the problem and have come across this myself before. It's just that from the point of view of the base class designer, if I say "ensure super.call()" I expect it to actually be part of all execution paths in the overrides. I don't really care if implementers completely forgot it or just messed up their control flow, my business logic demands that the call is made.

On another note, I would prefer to make this a warning because then we get the @:skipSuper part for free by simply disabling the warning locally with @:haxe.warning("-WEnsureSuper").

[ncannasse]

I don't think it should be a warning. If it's part of the specification it shouldn't be ignored and the app should not be able to successfully compile and launch.
Regarding the definition of ensureSuper, maybe @:requireSuper would convey it better ?

[RblSb]

I also wanted to suggest that, such meta is named as @mustCallSuper in Dart and @CallSuper in Android. Maybe it's also can be useful to add argument to restrict position of a super() call in function body, like:
@:mustCallSuper(First/Last)

[back2dos]

Seems like a terrible way to use inheritance. IMO this is better:

class Base {
  @:noCompletion final function _init() {
    trace("doing the super important generic thing");
    init();
  }
  function init() {}
}

class Derived extends Base {
  override function init() {
    trace("doing the super fancy specific thing");
  }
}

The base class retains control over the fact that things are called in the correct order. The derived one gets to run its logic at meaningful points in time.

I understand that some native frameworks/APIs have this, but this seems easy enough to check in Context.onGenerate, while dealing with various other constraints that exist in that particular use case.

[ncannasse]

If there's already a kind of standard for naming in other languages then using @:callSuper is fine with me. I won't go as far as enforcing order because there's no guarantee that's what the dev will always want. (For example adding a trace before/after would error).

PS @back2dos : that doesn't work with several levels or inheritance.

[barisyild]

class A {
     function init() { }
}
class B extends A {
     override function init() {
         super();
     }
}
class C extends A {
    override function init() {
        @:skip super();
    }
}

Wouldn't it be easier like @:inline

[barisyild]

class A {
function init() { }
}
class B extends A {
override function init() {
super();
}
}
class C extends A {
override function init() {
@:skip super();
}
}
Wouldn't it be easier like @:inline

or an alternative method to super?

class A {
     function init() { }
}
class B extends A {
     override function init() {
         super();
     }
}
class C extends A {
    override function init() {
        nop();
    }
}

[ncannasse]

Following the discussions I have updated my initial proposal. We're good to implement @Simn