Community
Participate
Working Groups
I would like to be able to deprecate methods and types when renaming them. The Rename... dialog would have a checkbox with a "Deprecate" label followed by a "Comment" entry field. Turning on the checkbox would perform the same operation as "Rename" except that the renamed item would NOT be deleted. Instead it would be marked with the Javadoc @deprecated tag followed by the comment the user entered if any. Eclipse rocks.
Move to JDT/UI.
Not committed.
More than just leaving the old code behind, I'd rather have the option to leave behind a stub. For eg, suppose I refactor OldF old_f(X x,Y y) {...} to NewF new_f(Y y,Z z) {...} Then I'd like to be able to automatically leave behind a stub, something like /** @deprecated Use new_f(Y y,Z z) instead */ OldF old_f(X unused,Y y){ return (OldF) new_f(y, null); } I'm working on this at the moment, though this is my first eclipse bug so no promises. The options I'm thinking of adding are [X] Update Known References [ ] Leave behind ( ) - Stub (O) - Original Code [X] - Deprecated Comment This change would be made both in Change Signature and Rename Method.
Markus, just to keep you in the loop.
OK. This is done. I'm not an eclipse contributor, how do I submit the fix for review and comment?
Add patches to this bug report and we will have a look at them.
Created attachment 18738 [details] Extra code added to ChangeSignatureRefactoring and ChangeSignatureWizard to implement requested functionality It works. I've added some unit tests and modified others and they work. I've been using an earlier version of it at work for a weeks and it works. Things can always be improved, but it's time for someone else to have a look at it.
Created attachment 18739 [details] updated junit test file ChangeSignatureTests and new and changed in and out files for same There are now 124 junit tests in this class.
Thanks for the patch, Ben. Unfortunately, I won't have time to look into this before M6, but I'll consider it for M7. Did you also implement it for RenameMethod? We can't offer this just for change method signature. Either both refactorings will get the functionality, or none.
> Did you also implement it for RenameMethod? I haven't. I'll do so.
Hmm. I've had a look at RenameMethod and it seems to be a completely seperate piece of code doing a subset of what ChangeSignature does. Unsurprisingly, RenameMethod is a lot simpler than ChangeSignature. I don't want to copy code from ChangeSignature to RenameMethod. Should I change the Rename Method wizard so that invokes the Change Signature refactoring and deprecate the rename method refactoring? <<My email is currently not working. I'll check this page regularly until it's fixed.>>
No, rename method should not use ChangeSignature, since ChangeSignature creates an AST for every compilation unit that references the method. This is unnecessary for RenameMethod. I guess we have to live with some code duplication here.
Sorry, this won't happen for 3.1. Offering more support for API stability will be addressed in 3.2. We will then look into supporting this in an uniform way in all refactorings where it is feasible (e.g. also for all kinds of moves, etc.).
Released patch from Philip with common implementation for Change Method Signature, Introduce Parameter, Rename Method, and Rename Field (constants). Filed bug 121200 for the move refactorings. Philip, could you please check the test cases in the attached patch and create a new patch if there are cases that your tests didn't catch? Thanks.
Created attachment 32397 [details] jdt.ui / jdt.ui.tests.refactoring I had a look at the test cases - I've integrated them into the existing ones. The attached patch contains the updated test files and fixes a problem with varargs.
Created attachment 32402 [details] jdt.ui / jdt.ui.tests.refactoring Updated patch - missed some test cases.
Released the patch to HEAD.
