Bug 67326

Summary: [refactoring] Rename related classes
Product: [Eclipse Project] JDT Reporter: David Corbin <dcorbin>
Component: UIAssignee: Markus Keller <markus.kell.r>
Status: ASSIGNED --- QA Contact:
Severity: enhancement    
Priority: P3 CC: benno.baumgartner, daniel_megert, gunnar, markus.kell.r, Mike_Wilson, remy.suen, sven.efftinge, tobias_widmer
Version: 3.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: fix candidate
Bug Depends on:    
Bug Blocks: 44178    
Attachments:
Description Flags
patch for renaming similar types none

Description David Corbin CLA 2004-06-15 14:28:15 EDT 
When I rename class Foo, I'd like to see an "check table", listing other classes
that start with Foo (and/or maybe end with Foo).  Checking any of these will
apply the same rename for any checked classes.

For example:

Parser->FooParser, would also offer "ParserTest" and rename it to
"FooParserTest" if checked.

Table->Chart would also offer SparseTable and rename it to  SparseChart.

I would also like to set a Project specfic-pattern that says "default check"
anything matching this pattern (.*Test, for example).
Comment 1 Dirk Baeumer CLA 2004-06-15 15:54:48 EDT 
Good suggestion, but not for 3.0.
Comment 2 Gunnar Wagenknecht CLA 2006-09-06 05:18:15 EDT 
I tried implementing this behavior using a rename participant and mimic the way it's done in RenameSupport. However, I failed reusing the new JavaRenameRefactoring(new RenameTypeProcessor(relatedType)) because it does not know about the initial rename and thus, I end up with old and the new compilation units, i.e. the old ones are changed too but not removed.

I assume this happens because the RenameTypeProcessor is not able to work in a "chained" mode where it gets a list of preceding renames to take into account when computing the changes for updating the references.

Any chance to get support for this in 3.3? I don't mind if the API would be internal/provisional.

Are there other ways I should explorer?
Comment 3 Martin Aeschlimann CLA 2006-09-06 07:03:43 EDT 
This might be impossble with the current participant story:
- we assume that changes from participants do not interfere with the original changes. You can do some guessing using the 
IJavaElementMapper and accessing changed files, but you're walking on thin ice.
- so I think this can currently only be added to the rename refactoring directly.

We don't have that on the plan for 3.3, if you're interested, contributions are welcome.
Comment 4 Markus Keller CLA 2006-09-06 07:17:23 EDT 
*** Bug 148016 has been marked as a duplicate of this bug. ***
Comment 5 Gunnar Wagenknecht CLA 2006-09-13 05:04:26 EDT 
Created attachment 50015 [details]
patch for renaming similar types

This is my first attempt of a possible patch. There are some open questions which I marked with a 'XXX' comment in the code.
Comment 6 Markus Keller CLA 2006-09-14 06:40:38 EDT 
Thanks, I'll review the patch in early 3.3 M3.
Comment 7 Markus Keller CLA 2006-10-30 06:48:07 EST 
I'm very sorry that I didn't find time to review the patch for M3. Increasing priority to finally get this done for M4.
Comment 8 Mike Wilson CLA 2008-04-12 11:19:53 EDT 
Just noticed that this is marked P2, and the last comment was that a patch was going to be reviewed for 3.3 M4. Is anything happening here? Do we still believe this is P2?
Comment 9 Markus Keller CLA 2008-04-14 05:54:59 EDT 
Sorry, this would be too big a behavior change for M7.