Community
Participate
Working Groups
N20050607 (but probably since M5) Signatures for ctors are not distinguishable from signatures for methods. Apparently ctor signatures specify a void (V) return type. This is a problem for us in code assist: - we don't want to render return types for constructor proposals - for javadoc access, we have to map the signatures to IMethods, which is ambiguous in this case: class Test { public Test(int i) {} public void Test(int i) {} } We need either a signature that carries constructor information, or more information on the CompletionProposal. Unfortunately, there is also no flag, otherwise we could use CompletionProposal.getFlags.
+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
