We’re rewarding the question askers & reputations are being recalculated! Read more.
5 Include supercat's suggestion, and yet another way to describe the distinction
source | link

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

@supercat suggests an alternative way of looking at it: conceptually, a reference variable holds the unique ID of the object it references, something that is fixed for the life of the object, and it is this that gets copied to the function in a call. This view also makes it clear that the function has no way to find, let alone modify, the variable in the caller's stack frame.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Another way of looking at it: pass-by-reference does not mean pass the reference held in the argument variable, it means create, in the function, a local variable that references the argument variable.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit! which also discusses argument-passing in Java RMI.

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit! which also discusses argument-passing in Java RMI.

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

@supercat suggests an alternative way of looking at it: conceptually, a reference variable holds the unique ID of the object it references, something that is fixed for the life of the object, and it is this that gets copied to the function in a call. This view also makes it clear that the function has no way to find, let alone modify, the variable in the caller's stack frame.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Another way of looking at it: pass-by-reference does not mean pass the reference held in the argument variable, it means create, in the function, a local variable that references the argument variable.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit! which also discusses argument-passing in Java RMI.

4 added 51 characters in body
source | link

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit! which also discusses argument-passing in Java RMI.

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit!

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit! which also discusses argument-passing in Java RMI.

3 Terminology: replace pushing with passing in a couple of places.
source | link

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' bindingsbinding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. PushingPassing an argument's address allows swap to work, but pushing thepassing an address it containsit contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit!

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' bindings necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Pushing an argument's address allows swap to work, but pushing the address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit!

There is a test for whether a language is pass-by-reference: can you write a swap function, such that after swap(a,b), the caller finds that the values of a and b are reversed? You cannot do this in Java, not even for objects.

Note that you cannot achieve this goal by swapping the internals of the two objects - while the data may change, the identity of the objects has not, and this has consequences. For one thing, any other variable in the program that referenced either object would also see the change.

To see why you cannot write this swap, consider a simplified model of the language, in which the value of a reference variable is the address of the object it is currently bound to (garbage collection complicates this picture in a way not relevant here.) Before the call to swap, the caller's stack frame has a slot for a, containing the address of object A, and a slot for b containing the address of B. When swap is called, it receives the values of a and b, which are the addresses of A and B respectively. Therefore, it is decoupled from the caller: there is simply no way for it to find the addresses of the slots for a and b within the caller's stack frame, and therefore no way to set them so that the caller will see them swapped.

Call-by-reference means exactly the opposite, by definition: the function accesses its arguments through the caller's variable bindings, so that changing one of its arguments' binding in the function necessarily changes it in the caller's stack frame. The term dates to a time when mainstream languages did not have objects or references as first-class entities, and when an argument was passed, either a copy of its value (in pass-by-value) or its address (in pass-by-reference) was pushed on to the stack so that the function could retrieve it. Passing an argument's address allows swap to work, but passing an address it contains does not.

Therefore, we can see that Java uses pass-by-value, not pass-by-reference.

See also Java is Pass-by-Value, Dammit!

2 Add historical context
source | link
1
source | link