Community
Participate
Working Groups
I20050118 Invoke code assist here: List list= new | In this situation, code completion currently returns type proposals, which I guess is correct, since any nested type constructor could be called. I have two requests, however: - Could we get constructor (method?) proposals for the types that are compatible with the LHS? These types are known and correctly appear with the hightest relevance already. - (less important) Could you filter out type proposals that do not have nested types, or is that too costly? As far as I can see, there is no way that such types could form a valid RHS after the "new" keyword.
> These types are known and correctly appear with the hightest > relevance already. This statement seems wrong - I was tricked by the fact that types of the same cu were proposed when invoking code completion without a prefix. I guess it is too costly to find out which types are compatible with the LHS, then?
ok to close
Deferred post 3.1
To be investigated for 3.2 M3
I tried to improve completion inside constructor name. My first idea was to propose the same kind of proposal as current constructor completion (eg. 'new Object(|'), but the performance are not sufficient. I tried two ways to solve this problem A) fist solution. 1 - use BasicSearchEngine.search to find all constructors 2 - propose all constructors given by this search request 3 - create a list of all types with a construtor 3 - use BasicSearchEngine.searchAllTypeNames to find all types 4 - propose constructors with no argument for all types which are not in the list of types with a construtor. Problems of this solution: - with an eclipse full source workspace if i try to complete 'new A' then completion take 13s the first time and 4s the seconde time. - the signature given by the completion proposal would be an unresolved signature (unlike all other proposals which are resolved signatures) B) second solution 1 - use BasicSearchEngine.search to find all constructors with a special search participant. This participant only memorize the list of documents which contain a constructor. 2 - use BasicSearchEngine.searchAllTypeNames to find all types 3 - propose constructor with no argument for all types which are not inside the list of document. 4 - resolve all types which are in the list of document 5 - resolve all constructors of the resolved types 6 - propose resolved construtor Problems of this solution: - with an eclipse full source workspace if i try to complete 'new A' then completion take 12s the first time and 9s the seconde time. The perfomance are bad because the search index doesn't not contain enough information. Currently the indexes contains for one contructor declaration only the selector, the number of parameters and the document which contains this declaration. That's why the solution A needs to parse all files which contain a contructor and the solution B needs to parse and resolve all types which contain a contructor. But add more information inside indexes could be impossible. The problem would be simpler if i don't need to find parameters types and names.
Deferred post 3.2
*** Bug 136906 has been marked as a duplicate of this bug. ***
See also bug 6930 for a request to get constructor proposals. It requests constructor proposals, but not the inference of types matching the expected type.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
