Bug 183189 - [extract method] Extract Method's occurrence finder can't handle constants in signature
Summary: [extract method] Extract Method's occurrence finder can't handle constants in...
Status: CLOSED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Benjamin Muskalla CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-19 10:03 EDT by Dani Megert CLA
Modified: 2019-10-16 19:56 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2007-04-19 10:03:02 EDT
I20070417-0800.

Have this:
	c.doIt(1);
	c.doIt(i);
	c.doIt(j);

If I extract c.doIt(j) it will also find and update c.doIt(i); but not c.doIt(1);
Comment 1 Martin Aeschlimann CLA 2007-04-20 09:59:55 EDT
Looks like a bug, indeed!
Comment 2 Benjamin Muskalla CLA 2009-08-23 16:23:15 EDT
Same applies to expression that would resolve to the same binding eg.

c.doIt(i+j)
Comment 3 Jean-Noel Rouvignac CLA 2012-01-20 02:21:43 EST
This seems related to bug 112072.

I will try to infer what is happening:
It look like the "Extract method refactoring" is only looking at like for like AST when attempting to match common code.
So if the AST of the code to be extracted contains a variable of type int (or String), then it will be able to extract common code if it also contains a variable of the same type.
However, what happens in this case is that there is a int literal (or String), but it is not a int (or String) variable hence why the extract method fails to recognize common code.

At least, the extract method code should be enhanced to recognize a literal as a variable-like and extract this literal like it does with a variable to support the sample refactoring provided by Dani Megert.
At best, the extract method code should be enhanced to look for expressions of the same type and extract this expression like it does with a variable to support the sample refactoring provided by Benjamin Muskalla. However, I understand that this could be much harder or have performance implications for the algorithm.
Comment 4 Jean-Noel Rouvignac CLA 2012-01-20 02:30:09 EST
For me the workaround is manageable but painful. It transforms a short operation into a long one. Here is my workflow:
* Extract methods on all the blocks of code I want to extract, so I often extract several methods to avoid any impact when doing the rest of the steps.
* Extract many local variables (Ctrl+Shift+I) on each of the methods
* Move the local variables out of the code to extract (Shift+Up)
* If the code is big enough, I then attempt an "Extract method"
** If it fails I open WinMerge, compare the code of 2 methods and look for differences.
*** Often variable names prevent me from seeing the real AST differences, so I rename them in Eclipse (Ctrl+Shift+R).
** So I go back and forth between Eclipse and WinMerge.
** Once I am happy I found the differences and make the code look the same in both method, then I do the "Extract method" and even then sometimes it fails, then I give up.
** I need to repeat the same process for every extracted methods that I want to extract further.

So if the current bug could be fixed, it would be a good improvement to the process above!
Comment 5 Eclipse Genie CLA 2019-10-16 19:56:56 EDT
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.

If you have further information on the current state of the bug, please add it. 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.