Bugzilla – Full Text Bug Listing
| Summary: | Refactoring - Move Method containing field accesses introduces obsolete parameter | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Stefan Mandel <Stefan.Mandel> | ||||||
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | jarthana | ||||||
| Version: | 4.15 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
Created attachment 271331 [details]
file after refactoring
Moving to UI to know more about why the parameter is retained in one of the cases. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. The bug has not been fixed until now. Summary: - Moving methods in class A containing field accesses to class B can be moved to B, but will always get an additional (useless) parameter of type A (that is getting passed this) - Moving methods in class A containing method accesses to class B can be moved to B, and the do not get the useless parameter Yet the worst problems (request for a parameter name, or ignoring the check that should have prevented from creating a placeholder method at the orinal place) seem to have been removed. |
Created attachment 271330 [details] files before refactoring I have tracked down an inconvenience in refactoring "Move Method". Consider following code: public class A { public int i; public void inc() { i++; } } class B { private A b; public void run() { method(b); } public void method(A b) { b.inc(); } } class C { private A b; public void run() { method(b); } public void method(A b) { b.i++; } } Now I choose the refactoring "Move Method" on C.method moving it to A.method. The refactoring dialog requires a parameter name from me - and the final code contains this parameter - although it is never used. Now consider the same action on B.method => A.method. The refactoring dialog does not require a dialog (as expected) and does not introduce a synthetic unused parameter. The difference between both scenarios seems to be that one (B, with convenient behavior) just calls methods, while the other (C, with unexpected behavior) accesses a field on the move method target. Even if the field access is read-only the refactoring introduces the unnessesary parameter. Is there a reason to distinguish both scenarios?