Bugzilla – Full Text Bug Listing
| Summary: | [move method] use existing field in target instead of creating a new parameter [refactoring] | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | bmiller |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
This is a valid request. However, it may be not enough. Consider moving foo()
to fB:
class A {
B fB;
X fX;
Y fY;
Z fZ;
void foo() {
fX.x(); fY.y(); fZ.z();
}
}
class B {
A fA;
X fX;
Y fY;
Z fZ;
}
This is the reason that we did not implement it to use a user-defined mapping,
but instead create new parameters. Basically, we would have to use type
constraints to determine whether we have to introduce a new parameter or could
use the (user-specified) field.
Where's the problem? After the move, B#foo() would look like this:
void foo() {
fA.fX.x();
fA.fY.y();
fA.fZ.z();
}
The fA in fA.sub() in worker() can of course only be dropped since fA is the
chosen "origin" field. But even if worker() was left as fA.fB.sub();, the
omission of the new parameter would be helpful.
The problem is that using fA instead of a new parameter only partially solves the problem (see example above). Additionally, there are malicious cases like "fA= something" which would result in "this= something". I'll have a look into it. |
I20050823-0800 When moving A#sub() to fB in the example below, it would be nice if I could use the field B#fA instead of creating an new parameter. class A { B fB; void sub() { subsub(); } void subsub() {} } class B { A fA; void worker() { fA.sub(); } } After the move, the class B should look linke this: void worker() { sub(); } void sub() { fA.subsub(); } This is an often encountered problem when splitting a class manually in two parts by moving methods one at a time.