Chris Smith said:
George Cherry said:
class TestPassByValue3 {
private static void change(StringBuilder s) {
s.replace(0, 3, "New");
}
public static void main(String[] args) {
StringBuilder a = new StringBuilder("Old");
change(a);
System.out.println(a); //Prints "New"
}
}
It's perhaps not a good idea to call this "TestPassByValue3", since the
result does not in ANY WAY depend on whether Java implements pass by
value or not. If you want to determine that, you need to use the lvalue
of the parameter. That's what I was trying to make clear all this time.
Your example is equivalent to the two examples of indirect values in my
original post, where the parameter passing mechanism is completely
irrelevant.
Okay, I see what you mean, but the purpose of
the above example was to show the op that passing
by value does NOT preclude the called method from
modifying an object on the heap referenced by
the parameter. Your first example
class TestPassByValue {
private static void change(String s) {
s = "New";
}
public static void main(String[] args) {
String a = "Old";
change(a);
System.out.println(a); //Prints "Old"
}
}
could give that misunderstanding. The reason
that your example is, I think, subject to confusing
the op about that is that you used a parameter
which referenced an immutable object. Yes,
your example does show that the assignment
to the formal by the called method does not
change the actual parameter in the caller's method,
but I think there is less confusing way to show this,
which follows.
The following example would have demonstrated
what you demonstrated without introducing the
possible confusion which I think your example could
cause.
class TestPassByValue4 {
private static void change(int i) {
i = i + 1;
System.out.println(i); //Prints 1
}
public static void main(String[] args) {
int i = 0;
change(i);
System.out.println(i); //Prints 0
}
}
Does what I just said make any pedagogical sense?
Boy, are we beating this subject to death, or what.
George W. Cherry
