4 ms·

> ...it passes the callee a reference to the variable. And that reference itself is a value-- it's a thing passed to the function and copied from somewhere in

> ...it passes the callee a reference to the variable. And that reference itself is a value-- it's a thing passed to the function and copied from somewhere in memory to a register. It's the interpretation of this value that makes it a reference to some other tangible item. Further, it's the implementation details behind the syntactic sugar, compiler optimizations, and runtime support that allow the developer to reason abstractly with references. Your Java example with String overlooks the fact that String is immutable: the object itself can't be modified. Use any other object type, allow doMotreStuff() to operate on the argument's properties, and you get the same effect as if passing by reference. My point is that the SO explanation isn't a good one precisely because you get this pass-by-reference behavior in Java. Yes, indeed, technically there's this value that gets passed to a function, and it's the value of the reference. And, yes, everything that "passes by reference" has to pass something and that something is the "value of the reference" so everything is technically, at the bottom of the abstract stack, "pass by value." But that's not helpful when attempting to help the newb understand why his object mutated in a method when "pass by value" is what he expected.

Twisol 6y ago
"call-by-reference" already has a technical meaning, and it is widely-misunderstood because "reference" is an overloaded term. Variables are cells that contain values. A better name for "call-by-reference" semantics is "call-by-variable", because the variable -- the value-containing cell -- is what is semantically received by the called function. Moreover, it doesn't matter how this is actually implemented, so long as a caller may effectively rebind a caller's variable. In Java, variables may contain either "reference values" or "primitive values". It is never possible, in Java, to rebind a caller's variable. (Consider that there is never a call site that could be rendered illegal by making a non-final argument final.) We should not call it "pass-by-reference", not only because it's incorrect but because, to your point, it's entirely misleading when "reference" already has a distinct meaning in Java. Pointers are strictly more powerful in a language than pass-by-reference. If you have pointers and pass-by-value, you can emulate pass-by-reference by providing a pointer value that points to a variable cell. So if you have pointers already, you don't strictly need call-by-reference. C# doesn't have pointers in the managed subset, because raw pointers can't be managed. But call-by-reference can be added relatively easily, so you can recover a small amount of what could be done if you had pointers. That's the purpose of the `ref` keyword. Java doesn't have pointers, either, but it also doesn't have call-by-reference. That makes it impossible to write the canonical example of call-by-reference, `int a = 1; int b = 2; swap(a, b)`. Instead, you must reify the concept of a cell in the first place, e.g. by wrapping each value in a one-element array, and pass those cells to `swap` instead.
MaxBarraclough 6y ago
Twisol's reply is very good, but I'll add this: > that reference itself is a value-- it's a thing passed to the function and copied from somewhere in memory to a register. I don't see your point here. Java always passes by value. This isn't an open question. Computer architecture, assembly code, and compiler specifics, are irrelevant. > it's the implementation details behind the syntactic sugar, compiler optimizations, and runtime support that allow the developer to reason abstractly with references. It isn't. References types, and parameter-passing, work however the language defines them to work. The language's implementation isn't relevant. > It's the interpretation of this value that makes it a reference to some other tangible item. In pass-by-reference, the parameter refers to the passed-in variable, and you aren't given a choice about it. If you assign to a parameter which was passed by reference, the change will be visible to the caller. This is different from passing a pointer by value (as in C) and from passing an object-reference by value (as in Java). (It's confusing that we use 'refer to' in two different senses. In Java, a reference-type variable 'refers to' an instance, but overwriting the variable does not impact the referred-to entity. In pass-by-reference, a parameter 'refers to' a variable, and overwriting does impact the referred-to entity. Perhaps we should instead say that in Java, a reference-type variable 'points to' an instance.) > Your Java example with String overlooks the fact that String is immutable It does not. The immutability of the String instance is irrelevant. Swap it out for another class type, or for an array type, and everything I wrote still applies. > Use any other object type, allow doMotreStuff() to operate on the argument's properties, and you get the same effect as if passing by reference. In Java, everything is passed by value, including Java's reference types. Sometimes, pass-by-value and pass-by-reference would behave the same. We could demonstrate this with a C# example. So what? I'm not talking about accessing the members of the referenced object, as that isn't instructive here. Using pass-by-reference would permit the reference-type variable itself to be modified. Again, it is irrelevant whether the object instance is immutable. An example where we don't use an immutable object, but it still matters that Java uses pass-by-value: private static void doStuff(int[] arr) { arr = null; // Only overwrites local copy. Reference types are passed by } // value. The assignment is invisible to the 'main' method. public static void main(String[] args) { int[] myArr_1 = {1,2,3}; int[] myArr_2 = myArr_1; // The value of local variable 'myArr_2' cannot be changed by this line: doStuff(myArr_2); assert(myArr_1 == myArr_2); // Ok. } > the SO explanation isn't a good one precisely because you get this pass-by-reference behavior in Java There is no pass-by-reference in Java. It is incorrect to say that Java sometimes passes by reference. Java has reference types, has no pointer types, and always passes by value. These are distinct concepts, with accepted terminology. > that's not helpful when attempting to help the newb understand why his object mutated in a method when "pass by value" is what he expected. Maybe so, then we should start by explaining Java, and only explain the terms pass-by-value and pass-by-reference later on. What we shouldn't do is teach an incorrect definition of pass-by-reference. Saying that Java uses pass-by-reference is simply wrong, and should cost a student marks on their exam.

Twisol 6y ago

"call-by-reference" already has a technical meaning, and it is widely-misunderstood because "reference" is an overloaded term. Variables are cells that contain values. A better name for "call-by-reference" semantics is "call-by-variable", because the variable -- the value-containing cell -- is what is semantically received by the called function. Moreover, it doesn't matter how this is actually implemented, so long as a caller may effectively rebind a caller's variable. In Java, variables may contain either "reference values" or "primitive values". It is never possible, in Java, to rebind a caller's variable. (Consider that there is never a call site that could be rendered illegal by making a non-final argument final.) We should not call it "pass-by-reference", not only because it's incorrect but because, to your point, it's entirely misleading when "reference" already has a distinct meaning in Java. Pointers are strictly more powerful in a language than pass-by-reference. If you have pointers and pass-by-value, you can emulate pass-by-reference by providing a pointer value that points to a variable cell. So if you have pointers already, you don't strictly need call-by-reference. C# doesn't have pointers in the managed subset, because raw pointers can't be managed. But call-by-reference can be added relatively easily, so you can recover a small amount of what could be done if you had pointers. That's the purpose of the `ref` keyword. Java doesn't have pointers, either, but it also doesn't have call-by-reference. That makes it impossible to write the canonical example of call-by-reference, `int a = 1; int b = 2; swap(a, b)`. Instead, you must reify the concept of a cell in the first place, e.g. by wrapping each value in a one-element array, and pass those cells to `swap` instead.

MaxBarraclough 6y ago

Twisol's reply is very good, but I'll add this: > that reference itself is a value-- it's a thing passed to the function and copied from somewhere in memory to a register. I don't see your point here. Java always passes by value. This isn't an open question. Computer architecture, assembly code, and compiler specifics, are irrelevant. > it's the implementation details behind the syntactic sugar, compiler optimizations, and runtime support that allow the developer to reason abstractly with references. It isn't. References types, and parameter-passing, work however the language defines them to work. The language's implementation isn't relevant. > It's the interpretation of this value that makes it a reference to some other tangible item. In pass-by-reference, the parameter refers to the passed-in variable, and you aren't given a choice about it. If you assign to a parameter which was passed by reference, the change will be visible to the caller. This is different from passing a pointer by value (as in C) and from passing an object-reference by value (as in Java). (It's confusing that we use 'refer to' in two different senses. In Java, a reference-type variable 'refers to' an instance, but overwriting the variable does not impact the referred-to entity. In pass-by-reference, a parameter 'refers to' a variable, and overwriting does impact the referred-to entity. Perhaps we should instead say that in Java, a reference-type variable 'points to' an instance.) > Your Java example with String overlooks the fact that String is immutable It does not. The immutability of the String instance is irrelevant. Swap it out for another class type, or for an array type, and everything I wrote still applies. > Use any other object type, allow doMotreStuff() to operate on the argument's properties, and you get the same effect as if passing by reference. In Java, everything is passed by value, including Java's reference types. Sometimes, pass-by-value and pass-by-reference would behave the same. We could demonstrate this with a C# example. So what? I'm not talking about accessing the members of the referenced object, as that isn't instructive here. Using pass-by-reference would permit the reference-type variable itself to be modified. Again, it is irrelevant whether the object instance is immutable. An example where we don't use an immutable object, but it still matters that Java uses pass-by-value: private static void doStuff(int[] arr) { arr = null; // Only overwrites local copy. Reference types are passed by } // value. The assignment is invisible to the 'main' method. public static void main(String[] args) { int[] myArr_1 = {1,2,3}; int[] myArr_2 = myArr_1; // The value of local variable 'myArr_2' cannot be changed by this line: doStuff(myArr_2); assert(myArr_1 == myArr_2); // Ok. } > the SO explanation isn't a good one precisely because you get this pass-by-reference behavior in Java There is no pass-by-reference in Java. It is incorrect to say that Java sometimes passes by reference. Java has reference types, has no pointer types, and always passes by value. These are distinct concepts, with accepted terminology. > that's not helpful when attempting to help the newb understand why his object mutated in a method when "pass by value" is what he expected. Maybe so, then we should start by explaining Java, and only explain the terms pass-by-value and pass-by-reference later on. What we shouldn't do is teach an incorrect definition of pass-by-reference. Saying that Java uses pass-by-reference is simply wrong, and should cost a student marks on their exam.