Community
Participate
Working Groups
Move refactoring should move private methods used in the selected block to the target class if such methods only called from the selected block. There could be some issues in case if these methods are using fields of the source class, but I believe the can be resolved the same as references from the selected block.
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
