The most accurate statement I've found is that JavaScript, much like Java, passes reference-by-value. Everything is passed by value, but if your value is an object, then the new scope gets a copy of the reference. If you modify the object by dereferencing (that is, `a.foo = "bar";`), your modifications to the object persist outside of your scope.
This is an important understanding to have when working with JavaScript.
A numeric value is put into the call stack.
Which in the case of references happens to be the address of pointee.
It is only pass by reference, if what is put into the call stack is the address of the actual variable on the caller stack holding the data.
As you mentioned elsewhere, these terms are well defined in computer science. But how JavaScript works doesn't match either of them.
It only creates confusion to force JavaScript assignment and parameter passing into one of those two categories. This is what has led to the widespread misconception that "primitives are passed by value, and objects are passed by reference."
We're not implementing JavaScript engines here, we're programming in JavaScript. Implementation details like addresses and pointers are unknown to our code. They may differ from one JavaScript engine to another, and even during a single run of your program as the engine decides on the fly how to optimize or de-optimize your code.
What matters is the observable behavior from the point of view of the running JavaScript code.
There are a few ways you could describe that behavior, such as my notion of a new "name" that refers to an existing "thing", or shkkmo's and andrewstuart2's "pass a reference by value". But it's not "pass by value" as that term is understood in other programming languages such as C/C++.
There is nothing to discuss here other than JavaScript developers trying to imagine stuff instead of learning the underlying literature concepts.
JavaScript is not a special snowflake language.
Computer Science describes how things are supposed to be, they don't change because of language X or Y.
An object's value is a memory location. When you pass it as an argument you're passing that value into the method. The analogy is more akin to casting than copying.
An exception to pass-by-value would be Forth; in the case of stack-based languages there really isn't a "pass" going on at all. But everything copies something for every non-inlined function call nowadays. Another instance where it's less obvious what is going on is a truly immutable language like Erlang or Haskell, where the "value" is quite likely still being passed via a pointer, but that's only relevant from the point of view of considering garbage collection behavior.
This makes the old "pass-by-value vs pass-by-reference" terminology vestigial to the modern software engineer, which is why the only place you'll encounter it is in school courses. A better way of understanding the modern issues is to ask what powers a passed-in value has and just ignore the old question.
Of course, to implement pass by reference, you tend to have to pass pointers around, but the point is that the language gives the illusion that the identifiers within a function's scope are locations specified by the caller.
I guess a takeaway is that in designing a language, one has to consider the relationship between an identifier, the mutable cell associated with the identifier, and the value stored in that cell. It seem that in common languages the identifier refers to the cell, but if the identifier is used in a value context, it evaluates to the value in the cell. Languages with pass-by-reference semantics let you make your own & function, so to speak.
(A weird example in C of this relationship is that an identifier for an array refers to a cell that contains the whole array, but, if you use the identifier in a value context, it becomes a pointer to the first element. One aspect of it not actually being a pointer is that you cannot replace its value with the pointer to another array.)
Anyway, an everything-must-be-a-first-class-object hard-liner would insist that pass-by-reference is the way of the past. But, sometimes it is not economical to get everything to be a first-class object. For instance, you might decide it is not worth trying to create a pointer type for referring to members of a packed struct, but it is not too hard to make a pass-by-reference feature for this (via copying).
In other words, pseudocoded:
x=1
changeMe(x)
write(x) // 2
So I guess it depends on what you mean by "nowadays" but I'd still consider C++ a modern language within "everything".
sub mutate {
$_[0] = "blue";
}
my $color = "red";
mutate($color);
print($color); # "blue"Even viewing sharing as a subtype of value, that's not true; call by need exists in modern languages (e.g., Haskell), and, in fact, classic call-by-reference is available in lots of languages, though not the exclusive model in any (and not the primary model in any current popular language I can think of.)
Except for obscure, seldom-used languages like C++ and C#.
If you can write
int a;
ParseInt("123", a);
Print(a); // print 123
PHP has pass-by-reference: http://php.net/manual/en/language.references.pass.php
The reason why I brought up languages like Forth is that there really did used to be languages that did not actually "pass" things by value. Forth had a true pass-by-reference, in which there is no second copy of anything, neither the value, nor a pointer to the value. Now it's a dead distinction, in the sense that pass-by-value and pass-by-reference used to be distinguishing, because everything is copying something. Which is why the distinction is sort of confusing to try to apply to modern languages, and produces lots of heat but no light; it's dead, inapplicable to the modern language landscape.
The proper question to be asking is what permissions/privileges are passed by a function's parameter, whether you're allowed to modify it and have the modifications visible to the caller, whether you're not allowed to modify it at all (immutable languages, for instance), or whether there's an entire ownership system around what the passed-in value represents (Rust), not whether or not something was copied when the function call was made. Trying to answer this question in terms of "pass-by-X" doesn't help, if for no other reason than pass-by-X implies there's only two possibilities, and I outlined three classes of possibilities above, each of which can have their own further nuances. Is Rust pass-by-reference or pass-by-value? Well, the question is invalid, in either the original or the modern mutation of the meaning.
That is an implementation detail completely depends on the VM. There is one very simple exception to your example: call inlining. Pass-by-reference is a behavior specification, not an implementation specification.
> Rust
If Rust emitted purely pass-by-value machine code, zero-cost-abstractions would be impossible in the language.
> A reference is basically a pointer that the language prevents you from doing pointer arithmetic on, and in many languages such as PHP, is simply automatically dereferenced for you.
Also, the implicit is usually pass-by-value.
function foo(a) { a++; }
function bar(ref a) { a++; }
b = 1;
foo(b); // Pass by value, implicit.
assert(b == 1);
bar(ref b); // Pass by reference.
assert(b == 2);
What do you mean? Maybe you mean "invalid" as in "no one should ask this anymore," but in case you mean "invalid" as in "is an apple an orange?" then
- It's strictly pass-by-value in the classic meaning. Sure, because of immutability there's the obvious optimization the compiler can do which is, under the hood, pass a pointer to a caller's value, but you could also implement everything by copying without the programmer noticing a difference (except for how long the program takes to run).
- It's strictly not pass-by-reference in the classic meaning. The "references" are a type of value. Parameters never are equivalent to the passed-in variable.
Whether or not it's a useful distinction to make is another story. References-as-values seems to be the emerging dominant paradigm for language design, but I sort of wish there were more languages that let you say "this variable is the fifth element of this array."
> if for no other reason than pass-by-X implies there's only two possibilities
I guess because people have only ever heard of by value and by reference, but there are a whole bunch more: by name, by copy-restore, by sharing.
PHP does all three, pass-by-value (simple values), pass-reference-by-value (objects and arrays), pass-by-reference (when using & prefix)
The terms still have important distinctions in modern languages as they are functionally different.
No, it doesn't. Heck, when I learned pass- (or call-)-by-X there were three main values of X mentioned (and implicitly a near-universal number of possible alternatives): value, reference, and name.
There are actually several more recognized values; the Wikipedia article on Evaluation Strategy has a reasonably good list:
I think making these distinctions is somewhat asinine and that it doesn't really do more than make people aware that the function call interface actually has some interesting design considerations. It's sort of like "ok, we have decided whether a hamburger is a sandwich. Now we can finally do the thing that desperately depended on this decision, which was, uhh..."
JS doesn't pass everything by reference. As you've shown in your code example. And JS doesn't actually pass anything by reference as you and Amarshal have shown in your comments (which I knew, but didn't at the same time... Thanks for enlighting me guys!).
But what's mind blowing is that the code example given doesn't actually have anything to do with pass by ref of value. It's checking that the attributes of objects are reference based. It's not actually checking the function argument. Just an attribute of the argument.
I've upvoted your comment and your subcomment/reply. Not that you or anyone cares. They're just points. But it's a shame your comment is being greyed out.
It is for objects, not primitives.
> JavaScript has 6 primitive data types: string, number, boolean, null, undefined, symbol (new in ES6). With the exception of null and undefined, all primitives values have object equivalents which wrap around the primitive values, e.g. a String object wraps around a string primitive. All primitives are immutable.
let a = {a: 1}
function foo(a) {
a = {a: 2}
}
foo(a)
a //=> {a: 1}
This would imply that:
var v = 1;
(function (o) {
o.a = 2;
}({ a: v });
console.log(v); // => 2
https://en.m.wikipedia.org/wiki/Evaluation_strategy#Call_by_...
let a = { bar: 'baz' };
function foo( a ) {
a = { beep: 'boop' };
}
foo( a );
console.log( a ); // { bar: 'baz' }$ node
> const b = { bar: 'baz' }
> function foo(a){ a = {beep: 'boop'}; }
> foo(b)
> console.log(b)
{ bar: 'baz' }
>
this is the gist of the issue, fetched from http://javadude.com/articles/passbyvalue.htm about java but exemplifies perfectly the pass by reference semantics:
"If you can write such a method/function in your language such that calling
Type var1 = ...; Type var2 = ...; swap(var1,var2); actually switches the values of the variables var1 and var2, the language supports pass-by-reference semantics."
as java javascript is reference-by-value
let a = function bar() { };
function foo( a ) {
a = 2;
}
foo( a );
console.log( a ); // bar let a = {key: 'a'};
function foo( a ) {
a = {otherKey: 'b'};
}
foo( a );
console.log( a ); // {key: 'a'} let a = {key: 'a'};
function foo( a ) {
a['otherKey'] = 'b';
}
foo( a );
console.log( a ); // {key: 'a',otherKey: 'b'} #include <stdlib.h>
// assume some hash table library, exercise for the reader
typedef struct{} *hashtable_t;
extern hashtable_t hashtable_init(void);
extern void hashtable_put(hashtable_t hashtable, const char* key, const char* value);
extern void hashtable_dump(hashtable_t hashtable);
typedef struct {
hashtable_t table;
} data_t;
void foo(data_t* a)
{
hashtable_put(a->table, "otherKey", "b");
}
int main(void)
{
// let a = {key: 'a'};
data_t* a = (data_t*) malloc(sizeof(data_t));
a->table = hashtable_init();
hashtable_put(a->table, "key", "a");
foo(a);
// console.log( a );
hashtable_dump(a->table);
return 0;
}
If C had pass-by-reference, it would be possible to give (implicitly) the memory location of the local variable a in main() instead. For example, like in Pascal (var) or C++ (& in function declaration).
If JavaScript allowed pass-by-referece, we would be able to do the following,
function swap(x, y) {
let c = x
x = y
y = c
}
let a = {a: 6, b: 7}
let b = {c: 8, d: 8}
swap(a, b)
console.log(b)
// Object {a: 6, b: 7}