Summary: | no way to distinguish constructor from method proposals | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tom Hofmann <eclipse> | ||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||
Status: | CLOSED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | david_audel, jeem, markus.kell.r | ||||
Version: | 3.1 | ||||||
Target Milestone: | 3.1 RC2 | ||||||
Hardware: | PC | ||||||
OS: | Linux-GTK | ||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 95181 | ||||||
Attachments: |
|
Description
Tom Hofmann
2005-06-07 12:00:00 EDT
+1 for RC2 Jim - what's your take here ? Basically we lost functionality from old to new API. We cannot tell the difference any longer in between constructor or method completion. Alternatives are: 1. use '<init>' as constructor name 2. introduce a new proposal kind (CONSTRUCTOR_REF) 3. introduce a predicate #isConstructor() 4. other? 3 is the least disrupting approach, but it feels like 1 should be fine too, and no extra method introduction. 5. We could return a key for METHOD_REF (CompletionProposal#getKey()). contructor key is Lp/Test;.()V method key is Lp/Test;.Test()V 5 requires that we commit in spec to the form of the keys (which I'm not sure we do, or would want to). For 1, we'd need to change the spec for CompletionProposal.get/setName to explain the special significance of "<init>", and change the implementation to return "<init>" instead of the class name as it does now. This is 3.0 API, so changing its behavior has its risks. 3 sounds like the best alternative: - add CompletionProposal.isConstructor() - change spec for CompletionProposal.get/setName() to say that the simple name of the class is used for METHOD_REF, METHOD_DECLARATION (and POTENTIAL_METHOD_DECLARATION ?) where constructors are involved. Created attachment 22596 [details]
Proposed patch
The new API is:
/**
* Returns whether this proposal is a constructor.
* <p>
* This field is available for the following kinds of
* completion proposals:
* <ul>
* <li><code>METHOD_REF</code> - return <code>true</code>
* if the referenced method is a constructor</li>
* <li><code>METHOD_DECLARATION</code> - return <code>true</code>
* if the declared method is a constructor</li>
* </ul>
* For kinds of completion proposals, this method returns
* <code>false</code>.
* </p>
*
* @return return <code>true</code> if the proposal is a constructor.
* @since 3.1
*/
public boolean isConstructor()
This is an API change. Needs approval. API change approved for 3.1RC2. Please clarify spec for CompletionProposal.get/setName() as well to say that the simple name of the class is used for METHOD_REF, METHOD_DECLARATION (and POTENTIAL_METHOD_DECLARATION ?) where constructors are involved. Fixed and tests updated CompletionTests#testCompletionFindConstructor() CompletionTests#testCompletionFindConstructor2() CompletionTests#testCompletionFindConstructor3() CompletionTests#testCompletionFindConstructor4() CompletionTests#testCompletionFindConstructor5() CompletionTests#testCompletionBasicAnonymousDeclaration1() CompletionTests#testCompletionKeywordSuper6() CompletionTests#testCompletionKeywordSuper12() CompletionTests_1_5#test0236() Added the new API CompletionProposal#isConstructor() and updated spec for CompletionProposal#setName() and CompletionProposal#getName(). Verified that API is available in N20050609-0010. There is a typo in the Javadoc. I entered bug 99397. Verified that the isConstructor() method is present in I20050610-0010 |