Add a "@final" rule?

[ChiriVulpes]

(or @sealed)

Example:

class Foo {
  /**
   * @final
   */
  public bar() {}
}

class Bar extends Foo {
  /**
   * @override
   */
  public bar() {} // errors, "bar is marked as 'final', it should not be overridden"
}

Caveats For Days:

1. I'm guessing it wouldn't be possible to implement this with decorators, since the presence of decorators isn't "exported" by Typescript (I'm not too sure the terminology of TS's innards). I'm guessing that TSLint doesn't get that information either, then. And that means you'd have to be able to look at the source code of the superclass method to check if it's decorated with @final or not, which might not even be possible if the superclass method is in another file.
   • Even if looking directly at the source code of other files is possible, this might be impossible to implement in an efficient way, if you have to look at the source of superclasses for every method (when those superclasses would probably be in other files).
2. Would this even be within this project's scope? They're related checks, but this project wasn't made with the "final" rule in mind.
   • Note: The efficiency of the "final" rule (if it existed) theoretically could be improved by piggybacking off the existence of stuff marked @override. So maybe that makes them a little more linked?

Note: Does implementing final in TSLint make more sense than having it as a keyword in Typescript? I think in a way it could be more helpful, because consumers could still override if they really wanted to and knew what they were doing, vs being locked out completely (unless you were to like manually assign the method or sth)

[hmil]

This is definitely out of scope. Although it is an interesting feature too.

Regarding performance, I'd trade some performance for separation of concerns since this stuff is all early work.

We could imagine having many of these features bundled in a larger module for convenience. (something like typescript-tslint-extensions, which would provide missing features of the language in the linter).

Also, remember that this module is intended as a discussion / exploration around the override keyword in TypeScript. It is not ideal to have to rely on a linter for that.