Repository navigation
Populate inheritied properties and methods in completion list inside a class #7158
Description
abstract calss B {
abstract getValue() : number;
}
class C extends B {
| // <= expect getValue to show.
}{{ message }}
abstract calss B {
abstract getValue() : number;
}
class C extends B {
| // <= expect getValue to show.
}
Activity
masaeedu commentedon Feb 21, 2016
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 commentedon Feb 22, 2016
I do not know about this one. currently you get no completion in an interface; I would start with class only.
That is correct
masaeedu commentedon Feb 22, 2016
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:
You would still get the same completion options.
mhegazy commentedon Feb 22, 2016
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,getandset.mihailik commentedon Feb 22, 2016
constructortoomasaeedu commentedon Feb 22, 2016
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 Mohamed Hegazy (@mhegazy) have mentioned (this is actually marked as a TODO in the code). I think this is best left to a separate PR.
masaeedu commentedon Feb 24, 2016
Mohamed Hegazy (@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 commentedon Feb 25, 2016
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
tryGetObjectLikeCompletionSymbolsortryGetImportOrExportClauseCompletionSymbols.masaeedu commentedon Feb 25, 2016
Gotcha, thanks. So the set of members to suggest (in addition to the keywords), is what would be suggested at
this.|, correct? I could recursively add all base type members, but there's edge cases to consider like private members.DanielRosenwasser commentedon Mar 2, 2016
Asad Saeeduddin (@masaeedu) yup, that sounds correct.
tinganho commentedon May 10, 2016
Could it be possible if this autocompletes the signature and not just the identifier?
mhegazy commentedon May 11, 2016
the API does not support a template-like completion at the moment. so either do identifiers only, or add a concept of replaceText to put the whole signature.
3 remaining items
RyanCavanaugh commentedon Mar 23, 2017
OmniRoot nope - you'll see someone in the "assigned" field before anyone begins work on it
Completion list for a class extending another class should contain me…
Completion list for a class extending another class should contain me…
pmunin commentedon Jul 17, 2017
Not sure I'm following the process here - the issue marked as closed, however I still see this problem in current version of VSCode:
Version 1.14.1
Commit 2648980a697a4c8fb5777dcfb2ab110cec8a2f58
Date 2017-07-13T19:18:47.188Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0
Typescript 2.4.1
How can I see from the issue, when it's planned to be in PROD?
bugproof commentedon Sep 21, 2017
doesn't work for me as well, I'm using React Native and it doesn't seem to complete this.setState for instance or any method from React.Component.
pmunin commentedon Sep 21, 2017
I guess someone needs to reopen or recreate the issue
doronnac commentedon Oct 13, 2017
Sheetal Nandi (@sheetalkamat) From what I can tell, method override autocompletion is not a desirable feature in VSCode and Typescript. Can you please confirm?
mhegazy commentedon Oct 16, 2017
We believe the issue has been fixed. if you are still running into issues please file a new ticket and provide enough information for us to reproduce it locally.
ChiriVulpes commentedon Feb 28, 2018
Is this not what this issue was for? I can't find any other issues that seem to talk about what I expect to happen, that all type & visibility information would be automatically inserted
Is this a bug or missing feature? Is there already an open issue for this?