History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: RSRP-5777
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Sergey Shkredov
Reporter: Colin
Votes: 2
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
ReSharper

Copy/Move method.

Created: 05 Aug 06 02:14   Updated: 17 Feb 08 00:39
Component/s: Refactorings
Fix Version/s: Future Versions
Security Level: Everybody (All jira users)

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

Build: 157
Old URL: http://www.intellij.net/tracker/resharper/viewSCR?publicId=5777


 Description  « Hide
I'm looking for a feature similar to copy/move type except with this I'm only wanting to copy/move a method. Upon right-clicking a method name and selecting copy/move I would expect a dialog to come up that has two multually exclusive options (denoted by radio buttons) The first would be "To existing class: " followed by a DDLB with all existing classes (perhaps separated by namespace for usability). The second option would be "New class: " followed by a textbox where you can enter the new class name.

 All   Comments   Work Log   Change History      Sort Order:
Ilya Ryzhenkov - 07 Aug 06 17:53
Re: #5777- Copy/Move method.
IMHO this is pretty strange feature. In most cases method will use fields, other methods. If you copy/move method to different class, should R#R copy/move used fields and other methods? Otherwise refactoring is breaking the code.

I can see when this feature is useful - for utility classes with only static members, which are stateless. But this is pretty rare case, copy/paste is enough.

I use Ctrl-W (Expand selection) to select entire member, then either copy or cut it. I sometimes use Ctrl-D to duplicate it in place.


Geoff Lane - 18 Dec 07 20:13
"Moving methods is the bread and butter of refactoring" – Martin Fowler (Refactoring, pg 142).
I think this is a very important refactoring. It's a fundamental means of fixing a design mistake.

Break up a complex algorithm using Extract a method
Move some of those methods to a more relevant class (e.g. a Data Access class)

Identify a method that acts mostly on another class's data
Move the method to that class

Of course you can do this manually, but that's true of every refactoring...

Can you take care of every scenario? Maybe not, but there are definitely cases that you can automate.

E.g.
Moving a method to an instance used within that method changes all of the references of that instance to 'this'.
Give user the option of moving, passing as arguments or (less desirable) copying referenced fields to the same location if necessary
Give user the option to copy dependent methods (if possible) to the new location as well
Warn of breaking the code in a move method in cases that aren't automateable?