Bug 67326 - [refactoring] Rename related classes
Summary: [refactoring] Rename related classes
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 enhancement with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard: fix candidate
Keywords:
: 148016 (view as bug list)
Depends on:
Blocks: 44178
  Show dependency tree
 
Reported: 2004-06-15 14:28 EDT by David Corbin CLA
Modified: 2010-11-04 06:44 EDT (History)
8 users (show)

See Also:


Attachments
patch for renaming similar types (26.58 KB, patch)
2006-09-13 05:04 EDT, Gunnar Wagenknecht CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.