Community
Participate
Working Groups
When method m introduces a new parameter (of type B) whose default value is new B(), m invocation will evaluate its argument expression new B() after the refactoring. When the argument expression has side effects, the change-method-signature may change program behavior. BEFORE ----------------------------------- class A { void m() {} void n() { new A().m(); } } AFTER ----------------------------------- class A { void m(B b) {} void n() { new A().m(new B()); // new B() may have side effects } }
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.
The refactoring creates the new class with a no-arg constructor. Side effects will only happen if the new class is changed.
Dani -- I showed an "example" above. Side effects can occur when the argument expression is not a simple variable. Read my comment again.
(In reply to Jongwook Kim from comment #3) > Dani -- I showed an "example" above. Side effects can occur when the > argument expression is not a simple variable. Read my comment again. There won't be a side effect as the constructor for B is created. If you disagree, please attach an example that can be executed and shows a different value after the refactoring.
BEFORE (Output: 0) ----------------------------------- class A { void m() {} void n() { new A().m(); } } class B { static int i = 0; B() { B.i++; } public static void main(String[] args) { new A().n(); System.out.println(B.i); } } AFTER (Output: 1) ----------------------------------- class A { void m(B b) {} void n() { new A().m(new B()); // new B() may have side effects } } class B { static int i = 0; B() { B.i++; } public static void main(String[] args) { new A().n(); System.out.println(B.i); } }
The attached code is not generated by the refactoring but changed by you after doing the refactoring. If I am wrong, please provide details steps that do not contain any code changes made by you and only use the refactoring.
(1) Select "Change Method Signature" refactoring on method m() (2) Click "Add" button to add a new parameter to method m() (3) Set "Type" to "B" (4) Set "Name" to "b" (5) Set "Default value" to "new B()" (6) Don't turn on the delegate option (7) Click "OK" button to run the refactoring
OK, got it. I was using the introduce parameter refactoring. Sorry for that.
That is OK. The previous title was misleading; Eclipse has another refactoring named "introduce parameter object".
My 2c: (In reply to Jongwook Kim from comment #7) > (5) Set "Default value" to "new B()" This is the user programming, not s.t. that the refactoring created. Hence the user should not be surprised if this expression produces a side-effect. (Some argue that constructors with side-effect are the problem to begin with). If we expect the refactoring to catch this, what should it do? Prohibit any non-trivial expressions in the "Default value" field? Would people be happy about that that limitation?
