Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 220304

Summary: [change method signature] should allow modification of all methods overloaded with same name
Product: [Eclipse Project] JDT Reporter: Luke Hutchison <luke.hutch>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: CLOSED INVALID QA Contact:
Severity: enhancement    
Priority: P5 CC: martinae
Version: 3.4   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Luke Hutchison CLA 2008-02-25 19:14:57 EST 
Build ID: M20071023-1652

Steps To Reproduce:
When using "Refactor->Change Method Signature", it is easy to forget to change all instances of an overloaded method or constructor to be consistent with one another.  This can result in confusing calling conventions.  

It would be great if Change Method Signature displayed a list containing a separate sublist of parameters for each equally-named method.  The actual one being refactored should show up first or be initially selected in the list.  The parameter order of any or all methods overloaded with the same name could then be updated in a single operation.
Comment 1 Martin Aeschlimann CLA 2008-02-26 03:40:18 EST 
Hmm, this is the first time I hear this suggestion; I also haven't had this scenario where this would have come handy.
Comment 2 Luke Hutchison CLA 2008-02-26 10:14:39 EST 
The example I hit yesterday was as follows: I had two constructors

  public Relationship(String childId, String parentId, String relationshipType) {}

  public Relationship(Term child, Term parent, RelType relationshipType) {}

I refactored the first one as follows:

  public Relationship(String childId, String relationshipType, String parentId) {}

I then noticed a call somewhere:

  x = new Relationship(child, parent, relType);

which I thought had been missed by the refactoring.  I spent a lot of time trying to duplicate the bug in a simple testcase, but couldn't, then I realized that this call was actually a call to the second constructor, which I didn't notice the existence of.

It would be great if the refactor display just displayed both calls:

  public Relationship : constructor
    String childId
    String parentId
    String relationshipType
  public Relationship : constructor
    Term child
    Term parent
    RelType relationshipType

It makes sense to do this because there are a lot of cases where overloaded functions should have parameters in approximately the same order, so that the calling conventions make sense.