Suggestion: Final keyword for classes and methods

[0815fox]

I'd like to have a final keyword on classes and methods, which specifies, that the class / method must not be overridden by any typescript class. Compile-time checks should be done, such that the following examples generate a tsc compiler error.

final class Foo {

}

class Bar extends Foo {

}
// => Bar cannot extend Foo, because it is final.

class Foo {
  final fooIt():void{

  }
}

class Bar {
  fooIt():void {

  }
}
// => Method fooIt of Bar cannot override fooIt of Foo, because it is final.

E.g. I often use following pattern, where I want to urgently avoid fooIt to be overridden:

import Whatever ...

abstract class Foo {
  private ImportantVariable:boolean;

  protected abstract fooIt_inner:Whatever();

  public final fooIt():Whatever() {
    //do somestate change to aprivate member here, which is very crucial for the functionality of every Foo:
    ImportantVariable = true;
    //call the abstract inner functionality:
    return this.fooIt_inner();    
  }
}

[kitsonk]

Dupe of #8306 which was closed as "won't fix" for the reasons listed in that issue.

[0815fox]

Only half of it. How would you provide a final keyword for methods?

Actually, I often see argumentations like those in #8306 in this issue tracker, which state, that something would not add any value, like mhegazy in the last comment of that closed issue. That's really a pitty, because it does add value. It prevents users from accidentially doing something unintended, when they want to extend functionality. Of course you can write a comment for that, but that is error prone. I can also write a comment that states, that a user should only pass in string for my argument x of my function. So why should I use Typescript then? I use it, because it adds value. It prevents me from making stupid mistakes in a large project with many involved parties and I am very happy to have it. So: why did they introduce the abstract keyword? what can they improve with this? Users could also write a comment which states, that the class should not be instanciated. And one could also avoid exposing it as class, like the argument in #8306.

[mhegazy]

This is indeed a duplicate of #8306. We would appreciate it if you can keep the discussion in one thread; it makes it easy to track all proposals, and limits noise. we do not lock closed issues, so feel free to comment on them as well.

[0815fox]

Then you should add the final keyword for methods topic to the title as well. Or shall I open another issue for the final statement on methods, which is not handled by #8306 at all?

[mhegazy]

I do think they are more or less the same issue to be frank.

[aluanhaddad]

So: why did they introduce the abstract keyword?

@0815fox it's worth noting that the abstract keyword affects code generation in a meaningful way.

Consider abstract-thing.ts

abstract class AbstractThing {
    abstract doSomething(): void;
}

abstract-thing.js

var AbstractThing = (function () {
    function AbstractThing() {
    }
    return AbstractThing;
}());

I'm not sure final methods could be emitted which would give a false sense of security. Now this is just my viewpoint. I avoid the private keyword for largely the same reason.

[0815fox]

I agree with you, there will probably be no mechanism which prevents final methods from being overridden in JavaScript. But overriding them from within typescript should be made impossible, unless you are doing crazy casts or use any.

For me, TypeScript is something like a safety belt. It will not protect someone, who drives without using it, but it should not be removed from cars, just because there are people doing this. Instead it adds security for those using it and does not affect those not using it.

But there is one important thing, which @mhegazy pointed out: They have a limited amount of time and try to use it wise on the most important features. I agree with him, that the final keyword is not the most important feature at the moment. I disagree with him, that it does not add value to the code.

It's a pitty, that they decided to close such issues, because it makes it harder to find them (search by default only shows open tickets). A dedicated label 'got it, but not now' might be more helpful. Then they could lock closed issues for new discussion, such that (partial) duplicates like this one are not commented to anymore.

@mhegazy: Can you somehow close and lock this ticket, such that everyone comments in the duplicate?

[aluanhaddad]

@0815fox I absolutely agree with making a distinction between closed vs pending issues. It would be nice if GitHub allowed a repository to configure the default search parameters used for searching issues. Even the term issue itself is not particularly descriptive in the sense that it has the wrong connotation for many things which need to be filed as issues. But these are GitHub issues and are far outweighed by the benefits of the overall platform.

[mhegazy]

closing in favor of f #8306.