Summary: | [move method][refactoring] Move refactoring should move private methods | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Eugene Kuleshov <ekuleshov> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P4 | CC: | christof_marti, deepakazad, eclipse, erlend.k, mlists, reprogrammer |
Version: | 3.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
Eugene Kuleshov
2003-11-28 10:32:43 EST
Moving things for free isn't the right thing to do. The only enhancement I can think of adding a button to compute all dependencies and let the user decide what to do with this. Ok. Let me rephrase my bug. Eclipse should analyse if there are provate methods that only called from the selected block and SUGGEST to move such methods into the target too. Otherwise we are having the following situation. ----- // Source code { ... SomeClass b; privateMethod( b) ... } private privateMethod( SomeClass b) { ... } ------- changed to the following. Notice "this"! ------- b.newMethod( this, b) ------- and result is broken anyway because privateMethod() can't be called from SomeClass. Moving multiple members to a field's type often occurs when splitting an existing class. Using individual move operations does not have the same result, unless the dependencies among the moved members form a tree and one moves them depth-first, otherwise a moved method might need an additional parameter, pointing back to its original containing type. It would be good to analyse a method if it does any access to the instance and use 'move static method' if possible |