Populate inheritied properties and methods in completion list inside a class

[mhegazy]

abstract calss B {
    abstract getValue() : number;
}

class C extends B {
    | // <= expect getValue to show.
}

[masaeedu]

Should the same be done for ancestor interface members as well? Also, once the member has been implemented, should it stop being displayed in the completion list?

[mhegazy]

Should the same be done for ancestor interface members as well?

I do not know about this one. currently you get no completion in an interface; I would start with class only.

Also, once the member has been implemented, should it stop being displayed in the completion list?

That is correct

[masaeedu]

currently you get no completion in an interface

What I mean is that you should get completion in a class deriving from an interface, just as you would in a class deriving from an abstract class. For example, if you had:

interface B {
    getValue() : number;
}

class C extends B {
    | // <= expect getValue to show.
}

You would still get the same completion options.

[mhegazy]

i also should add, that in the absence of these completions, only applicable keywords should be shown, i.e. public, private, protected, static, abstract, readonly, get and set.

[mihailik]

constructor too

[masaeedu]

@mihailik I'm not changing the completion options that would normally be populated at that location, just adding some extras. Right now the list isn't limited to the applicable keywords you and @mhegazy have mentioned (this is actually marked as a TODO in the code). I think this is best left to a separate PR.

[masaeedu]

@mhegazy Could we open a new issue with the exact specification for what should and shouldn't be suggested in a class body? Unimplemented abstract ancestor members are PRed in #7190.

[DanielRosenwasser]

Just because a base member is not abstract doesn't mean you can't override it. So only taking abstract members probably isn't the right approach.

So let's say all base class members which are not currently overridden should be listed as suggestions in the body of a class. But it's not quite that simple. If a member exists, you might still be defining an overload, so you definitely don't want to remove that from a completion list.

So as a first step, the completion list should consist of the above suggested keywords, alongside any base members. Don't worry about filtering candidates out for now.

For examples of how to approach this, take a look at tryGetObjectLikeCompletionSymbols or tryGetImportOrExportClauseCompletionSymbols.