Community
Participate
Working Groups
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.
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.
