Arrays are passed by reference in javascript. That means arrays are mutable and can be changed in called function. Why am I not able to Re-initialization an array in called function?
This is also true for python
function calling(){
var arr = [1,2]
console.log(arr); //prints [1,2]
called(arr);
console.log(arr); //prints [1,2,3,4],but I was expecting [5,6]
}
function called(arr){
arr.push(3)
arr.push(4)
arr = [5,6]
}
calling()
UPDATE
I am seeking justification of (mutability, pass by reference, pass by assignment and re-initialization of an array)
Please don't post workaround and solution of the problem. I know how to get arr to print [5,6]
Arrays are passed by reference in javascript.
No, they aren't. ECMAScript/JavaScript is strictly pass-by-value. (More precisely, call-by-sharing, which is a special case of pass-by-value.)
That means arrays are mutable and can be changed in called function.
No, that's not what it means. It means exactly what it says: that the reference within the caller's scope to the array is passed as an argument into the function, and not the value.
Whether or not the array is mutable or not has nothing to with pass-by-reference vs. pass-by-value. ECMAScript is not a purely functional language, most objects can be mutated. Numbers, Symbols, and Strings are an exception.
Why am I not able to Re-initialization an array in called function?
You are trying to modify the reference within the caller's scope. That only works with pass-by-reference. ECMAScript is not pass-by-reference, whoever told you that is simply wrong.
This is also true for python
Python behaves identically to ECMAScript in this regard, yes, it is also pass-by-value.
Your confusion stems from the fact that you erroneously believe ECMAScript/JavaScript is pass-by-reference, when in fact it is not.
ECMAScript uses pass-by-value, or more precisely, a special case of pass-by-value where the value being passed is always a pointer. This special case is also sometimes known as call-by-sharing, call-by-object-sharing or call-by-object.
It's the same convention that is used by Java (for objects), C# (by default for reference types), Smalltalk, Python, Ruby and more or less every object-oriented language ever created.
Note: some types (e.g. Numbers) are actually passed directly by value and not with an intermediary pointer. However, since those are immutable, there is no observable behavioral difference between pass-by-value and call-by-object-sharing in this case, so you can greatly simplify your mental model by simply treating everything as call-by-object-sharing. Just interpret these special cases as internal compiler optimizations that you don't need to worry about.
Here's a simple example you can run to determine the argument passing convention of ECMAScript (or any other language, after you translate it):
function isEcmascriptPassByValue(foo) {
foo.push('More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value!');
foo = 'No, ECMAScript is pass-by-reference.';
return;
}
var bar = ['Yes, of course, ECMAScript *is* pass-by-value!'];
isEcmascriptPassByValue(bar);
console.log(bar);
// Yes, of course, ECMAScript *is* pass-by-value!,
// More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value!
def is_python_pass_by_value(foo):
foo[0] = 'More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value!'
foo = ['Python is not pass-by-reference.']
quux = ['Yes, of course, Python *is* pass-by-value!']
is_python_pass_by_value(quux)
print(quux[0])
# More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value!
If you are familiar with C#, it is a very good way to understand the differences between pass-by-value and pass-by-reference for value types and reference types, because C# supports all 4 combinations: pass-by-value for value types ("traditional pass-by-value"), pass-by-value for reference types (call-by-sharing, call-by-object, call-by-object-sharing as in ECMAScript), pass-by-reference for reference types, and pass-by-reference for value types.
(Actually, even if you don't know C#, this isn't too hard to follow.)
// In C#, struct defines a value type, class defines a reference type
struct MutableCell
{
public string value;
}
class Program
{
// the ref keyword means pass-by-reference, otherwise it's pass-by-value
// You must explicitly request pass-by-reference both at the definition and the call
static void IsCSharpPassByValue(string[] foo, MutableCell bar, ref string baz, ref MutableCell qux)
{
foo[0] = "More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value.";
foo = new string[] { "C# is not pass-by-reference." };
bar.value = "For value types, it is *not* call-by-sharing.";
bar = new MutableCell { value = "And also not pass-by-reference." };
baz = "It also supports pass-by-reference if explicitly requested.";
qux = new MutableCell { value = "Pass-by-reference is supported for value types as well." };
}
static void Main(string[] args)
{
var quux = new string[] { "Yes, of course, C# *is* pass-by-value!" };
var corge = new MutableCell { value = "For value types it is pure pass-by-value." };
var grault = "This string will vanish because of pass-by-reference.";
var garply = new MutableCell { value = "This string will vanish because of pass-by-reference." };
// the first two are passed by value, the other two by reference
IsCSharpPassByValue(quux, corge, ref grault, ref garply);
Console.WriteLine(quux[0]);
// More precisely, for reference types it is call-by-object-sharing, which is a special case of pass-by-value.
Console.WriteLine(corge.value);
// For value types it is pure pass-by-value.
Console.WriteLine(grault);
// It also supports pass-by-reference if explicitly requested.
Console.WriteLine(garply.value);
// Pass-by-reference is supported for value types as well.
}
}
If you want to get technical, Javascript is really only "pass by value" - it is not "pass by reference". When you pass an object (like an Array), you are passing by value and the value is a reference (a copy of a reference to the array, not a copy of the actual array). This means you can use the value reference to mutate the original object, but it's not an actual reference to the original variable so you can't affect the contents of the original variable itself (e.g. you can't cause that other variable to point at a new object).
Since this language jargon doesn't actually explain what is going on for many folks, what follows here is more of a description of how it works:
When you do:
arr = [5,6]
inside your function, you are just assigning a new array to the arr function argument. You've just instructed Javascript to take the arr argument variable and point it at a new array object. That has no effect at all on the original array object that was passed into the function. It still happily exists in its other life.
You could change that array like this:
function called(arr){
arr.push(3)
arr.push(4)
// now set arr back to [5,6]
arr[0] = 5;
arr[1] = 6;
arr.length = 2;
}
It's a bit of a misnomer to say arrays are passed by reference because it isn't really a full reference like you would find in C++, for example. Some people say it's "pass by sharing" or "pass by pointer". Some people even call it "pass by value, but the value is a reference" which is probably technically correct, but doesn't usually help newbies understand what is going on. In my brain (partly because I know C/C++), I think of it like "pass by pointer".
Though Javascript doesn't actually have it's own data type that is a pointer, passing an array works more like passing a pointer works in C++. If you index off the pointer, you are accessing the original object:
arr[0] = 5; // this changes the original object
But, if you reassign the pointer a new value:
arr = [5,6]; // this just makes arr point at a new and different array
Then, you are just making the pointer variable itself point at a new object and the original object still remains untouched.
So, in summary. If you reference arr as in arr.push(x), then you are mutating the original array object.
But, if you assign arr a new array as in arr = [5,6], then you are just telling Javascript that you want the arr variable to point at a new array. Your arr variable in that function now points at a different array than it did before. The original array can no longer be reached by this code. But any other code that was pointing at that original array is still pointing at that original array. If you know C/C++, it actually works fairly similarly to a pointer in C++.
Here's a simpler example that is outside of the context of a function argument:
var x = [1,2];
var y = x;
console.log(x); // [1,2]
console.log(y); // [1,2]
y = [3,4];
console.log(x); // [1,2]
console.log(y); // [3,4]
You've merely asked y to now point to a new array [3,4]. Assigning y to point to a new array does not affect the original array at all.
In this example, the variable y is like the arr function argument in your called() function. Assigning a new value to it doesn't change the original in any way.
In Python:
In [170]: def called(arr):
.....: arr.append(3)
.....: arr.append(4)
.....: arr=[5,6]
.....:
In [171]: arr=[1,2]
In [172]: called(arr)
In [173]: arr
Out[173]: [1, 2, 3, 4]
Initially in called, arr is a reference to the mutable list [1,2]. The 2 append calls modify that list. But the arr=[5,6] step reassigns the variable. The link to outside arr is broken, so there's no further change.
If I'd added a return arr statement to the call,
In [175]: called(arr)
Out[175]: [5, 6]
In [176]: arr
Out[176]: [1, 2, 3, 4, 3, 4]
I modify the global arr again, but return the [5,6].
called would be clearer if written:
def called(arr):
arr.append(3)
arr.append(4)
res=[5,6]
return res
The last 2 lines have nothing to do with initial arr argument, so there is not point in reusing the variable name.
For further illustration of what is going on, look at the object id at various points:
In [178]: def called(arr):
arr.append(3)
arr.append(4)
print(id(arr))
arr = [5,6]
.....: return arr
.....:
In [179]: id(arr)
Out[179]: 2999818796
In [180]: id(called(arr))
2999818796 # id of global arr
Out[180]: 2999999564 # id of returned list
In [181]: id(arr)
Out[181]: 2999818796
Related
I am trying to understand what a Javascript immutable variable means. If I can do:
var x = "astring";
x = "str";
console.log(x); //logs str` , then why it is immutable?
The only answer I can think (from the little bit of C I know) is that var x is a pointer to a memory block with the value "astring", and after the 2nd statement it points to another block with the value "str". Is that the case?
And a bonus question: I was confused by the value types of Javascript. Are all variables objects under the hood? Even number and strings?
Values are immutable; variables are not; they hold a reference to their (primitive) values.
The three primitive types string, number and boolean have corresponding types whose instances are objects: String, Number, Boolean.
They are sometimes called wrapper types.
The following values are primitive:
Strings: "hello"
Numbers: 6, 3.14 (all numbers in JavaScript are floating point)
Booleans: true, false
null: usually explicitly assigned
undefined: usually the default (automatically assigned) value
All other values are objects, including wrappers for primitives.
So:
Objects are mutable by default
Objects have unique identities and are compared by reference
Variables hold references to objects
Primitives are immutable
Primitives are compared by value, they don’t have individual identities
You might find The Secret Life of JavaScript Primitives a good explanation.
Also, in ES6 there is a new const keyword, that creates a read-only named constant that cannot change value through assignment or be re-declared while the script is running.
Hope this helps!
First, in C "A string is an array of characters with last elem = '\0' ". They are mutable.
If you declare and initialize a string in C like this:
char str[] = "Foo";
What you are basically doing is reserving 4 bytes ( probably 8bit-byte, don't mind this probably if it hurts you ). The word str serves as a pointer to the first elem of this array. So, if you do like this:
str[0] or *(str) = 'G'
then it will mutate the value at that address instead of creating new array. You can verify it by printing out the address of str. In both cases it will be same.
Now in case of JavaScript string is a primitive type. All operations on string are done by value instead of by reference. So, doing this will produce true.
var str1 = "foo";
var str2 = "foo";
str1 === str2; => true
The initialization of string asks for a buffer to fit "foo" and binds the name str1 to it. What makes them immutable is that you can't change that buffer. So, you can't do this:
str1[0] = 'G'
Executing this command will produce no warning or error in non-strict mode but, it will not change the str1. You can verify it by
console.log(str1) => "foo"
But if you do like this:
str1 = "goo"
what you are actually doing is that you are asking for a new buffer to fit "goo" and bind identifier str1 to it. No change in that old buffer containing "foo".
So, what happens to "foo"?
Java Script has an automatic garbage collector. When it sees some chunk of memory that no longer can be referenced by any identifier or ... then it consider that memory free.
Same happens to number,booleans.
Now, about wrapper objects!
Whenever you try to access a property on string like this:
str1.length;
What JavaScript does it creates a new object using String class and invoke the methods on string. As soon as the function call returns, the object is destroyed.
The below code explains it further:
var str = "nature";
str.does = "nurtures"; //defining a new property;
console.log(str.does) => undefined
because the object has been destroyed.
Try this!
var str = new String("Nature");
str.does = "nurtures";
console.log(str) => ??
this str is really an object...
Conclusion: In C , in a single scope the variable name serves as a pointer. So, int, float, string all are mutable. But in Java Script a primitive type variable name serves as value not as reference
References: C++ primer plus, Java Script The Definitive Guide, C by Stephen Kochan
You are correct. Strings (and numbers) are immutable in java script (and many other languages). The variables are references to them. When you "change the value of a variable" you are changing the string (or whatever) that the variable references, not the value itself.
I think many new programmers believe immutability to mean that primitive values cannot be changed by reassignment.
var str = "testing";
var str = "testing,testing";
console.log(str); // testing, testing
var fruits = ["apple", "banana", "orange"];
fruits[0] = "mango";
console.log(fruits); //["mango", "banana", "orange"]
The values associated with both mutable and immutable types can be changed through reassignment as the above examples with strings and arrays show.
But then, these data types have associated functions(methods) that are used to manipulate the values belonging to each data type. This is where mutability/immutability is seen. Since arrays are mutable, any manipulation by an array method affects the array directly. For example,
var fruits = ["mango","banana", "orange"];
fruits.pop();
console.log(fruits) //["mango", "banana"]
The array.pop() method deleted "orange" from the original fruits array.
But with strings for example,
var name = "Donald Trump";
name.replace("Donald", "President");
console.log(name)//Donald Trump
the original string remains intact!
Immutability disallowed any altering of the original string by the string method. Instead, the method produces a new string if the method operation is assigned to a variable like so:
var name = "Donald Trump";
var newName = name.replace("Donald", "President");
console.log(newName);//President Trump
Let's understand here, first,
let firstString = "Tap";
console.log(firstString); //Output: Tap
firstString[0] = "N";
console.log(firstString) //Output: Tap
This is where we can see the immutable effect!
Immutability in this definition is historic. It's attached to what could be done in OTHER programming languages.
I think that is the first thing to understand. And to programmers who have only used JavaScript the question may seem nonsensical or needlessly pedantic. Describing primitives as immutable is like describing ice cream as not being able to jump. Why would I think it could? It is only in relation to other historic programming languages that the lack of mutability is apparent when dealing with primitive types.
So I was playing around the other day just to see exactly how mass assignment works in JavaScript.
First I tried this example in the console:
a = b = {};
a.foo = 'bar';
console.log(b.foo);
The result was "bar" being displayed in an alert. That is fair enough, a and b are really just aliases to the same object. Then I thought, how could I make this example simpler.
a = b = 'foo';
a = 'bar';
console.log(b);
That is pretty much the same thing, isn't it? Well this time, it returns foo not bar as I would expect from the behaviour of the first example.
Why does this happen?
N.B. This example could be simplified even more with the following code:
a = {};
b = a;
a.foo = 'bar';
console.log(b.foo);
a = 'foo';
b = a;
a = 'bar';
console.log(b);
(I suspect that JavaScript treats primitives such as strings and integers differently to hashes. Hashes return a pointer while "core" primitives return a copy of themselves)
In the first example, you are setting a property of an existing object. In the second example, you are assigning a brand new object.
a = b = {};
a and b are now pointers to the same object. So when you do:
a.foo = 'bar';
It sets b.foo as well since a and b point to the same object.
However!
If you do this instead:
a = 'bar';
you are saying that a points to a different object now. This has no effect on what a pointed to before.
In JavaScript, assigning a variable and assigning a property are 2 different operations. It's best to think of variables as pointers to objects, and when you assign directly to a variable, you are not modifying any objects, merely repointing your variable to a different object.
But assigning a property, like a.foo, will modify the object that a points to. This, of course, also modifies all other references that point to this object simply because they all point to the same object.
Your question has already been satisfyingly answered by Squeegy - it has nothing to do with objects vs. primitives, but with reassignment of variables vs. setting properties in the same referenced object.
There seems to be a lot of confusion about JavaScript types in the answers and comments, so here's a small introduction to JavaScript's type system:
In JavaScript, there are two fundamentally different kinds of values: primitives and objects (and there is no thing like a 'hash').
Strings, numbers and booleans as well as null and undefined are primitives, objects are everything which can have properties. Even arrays and functions are regular objects and therefore can hold arbitrary properties. They just differ in the internal [[Class]] property (functions additionally have a property called [[Call]] and [[Construct]], but hey, that's details).
The reason that primitive values may behave like objects is because of autoboxing, but the primitives themselves can't hold any properties.
Here is an example:
var a = 'quux';
a.foo = 'bar';
document.writeln(a.foo);
This will output undefined: a holds a primitive value, which gets promoted to an object when assigning the property foo. But this new object is immediately discarded, so the value of foo is lost.
Think of it like this:
var a = 'quux';
new String(a).foo = 'bar'; // we never save this new object anywhere!
document.writeln(new String(a).foo); // a completly new object gets created
You're more or less correct except that what you're referring to as a "hash" is actually just shorthand syntax for an Object.
In the first example, a and b both refer to the same object. In the second example, you change a to refer to something else.
here is my version of the answer:
obj = {a:"hello",b:"goodbye"}
x = obj
x.a = "bonjour"
// now obj.a is equal to "bonjour"
// because x has the same reference in memory as obj
// but if I write:
x = {}
x.a = obj.a
x.b = obj.b
x.a = "bonjour"
// now x = {a:"bonjour", b:"goodbye"} and obj = {a:"hello", b:"goodbye"}
// because x points to another place in the memory
You are setting a to point to a new string object, while b keeps pointing to the old string object.
In the first case you change some property of the object contained in the variable, in the second case you assign a new value to the variable. That are fundamentally different things. The variables a and b are not somehow magically linked by the first assignment, they just contain the same object. That's also the case in the second example, until you assign a new value to the b variable.
The difference is between simple types and objects.
Anything that's an object (like an array or a function) is passed by reference.
Anything that's a simple type (like a string or a number) is copied.
I always have a copyArray function handy so I can be sure I'm not creating a bunch of aliases to the same array.
I am trying to understand what a Javascript immutable variable means. If I can do:
var x = "astring";
x = "str";
console.log(x); //logs str` , then why it is immutable?
The only answer I can think (from the little bit of C I know) is that var x is a pointer to a memory block with the value "astring", and after the 2nd statement it points to another block with the value "str". Is that the case?
And a bonus question: I was confused by the value types of Javascript. Are all variables objects under the hood? Even number and strings?
Values are immutable; variables are not; they hold a reference to their (primitive) values.
The three primitive types string, number and boolean have corresponding types whose instances are objects: String, Number, Boolean.
They are sometimes called wrapper types.
The following values are primitive:
Strings: "hello"
Numbers: 6, 3.14 (all numbers in JavaScript are floating point)
Booleans: true, false
null: usually explicitly assigned
undefined: usually the default (automatically assigned) value
All other values are objects, including wrappers for primitives.
So:
Objects are mutable by default
Objects have unique identities and are compared by reference
Variables hold references to objects
Primitives are immutable
Primitives are compared by value, they don’t have individual identities
You might find The Secret Life of JavaScript Primitives a good explanation.
Also, in ES6 there is a new const keyword, that creates a read-only named constant that cannot change value through assignment or be re-declared while the script is running.
Hope this helps!
First, in C "A string is an array of characters with last elem = '\0' ". They are mutable.
If you declare and initialize a string in C like this:
char str[] = "Foo";
What you are basically doing is reserving 4 bytes ( probably 8bit-byte, don't mind this probably if it hurts you ). The word str serves as a pointer to the first elem of this array. So, if you do like this:
str[0] or *(str) = 'G'
then it will mutate the value at that address instead of creating new array. You can verify it by printing out the address of str. In both cases it will be same.
Now in case of JavaScript string is a primitive type. All operations on string are done by value instead of by reference. So, doing this will produce true.
var str1 = "foo";
var str2 = "foo";
str1 === str2; => true
The initialization of string asks for a buffer to fit "foo" and binds the name str1 to it. What makes them immutable is that you can't change that buffer. So, you can't do this:
str1[0] = 'G'
Executing this command will produce no warning or error in non-strict mode but, it will not change the str1. You can verify it by
console.log(str1) => "foo"
But if you do like this:
str1 = "goo"
what you are actually doing is that you are asking for a new buffer to fit "goo" and bind identifier str1 to it. No change in that old buffer containing "foo".
So, what happens to "foo"?
Java Script has an automatic garbage collector. When it sees some chunk of memory that no longer can be referenced by any identifier or ... then it consider that memory free.
Same happens to number,booleans.
Now, about wrapper objects!
Whenever you try to access a property on string like this:
str1.length;
What JavaScript does it creates a new object using String class and invoke the methods on string. As soon as the function call returns, the object is destroyed.
The below code explains it further:
var str = "nature";
str.does = "nurtures"; //defining a new property;
console.log(str.does) => undefined
because the object has been destroyed.
Try this!
var str = new String("Nature");
str.does = "nurtures";
console.log(str) => ??
this str is really an object...
Conclusion: In C , in a single scope the variable name serves as a pointer. So, int, float, string all are mutable. But in Java Script a primitive type variable name serves as value not as reference
References: C++ primer plus, Java Script The Definitive Guide, C by Stephen Kochan
You are correct. Strings (and numbers) are immutable in java script (and many other languages). The variables are references to them. When you "change the value of a variable" you are changing the string (or whatever) that the variable references, not the value itself.
I think many new programmers believe immutability to mean that primitive values cannot be changed by reassignment.
var str = "testing";
var str = "testing,testing";
console.log(str); // testing, testing
var fruits = ["apple", "banana", "orange"];
fruits[0] = "mango";
console.log(fruits); //["mango", "banana", "orange"]
The values associated with both mutable and immutable types can be changed through reassignment as the above examples with strings and arrays show.
But then, these data types have associated functions(methods) that are used to manipulate the values belonging to each data type. This is where mutability/immutability is seen. Since arrays are mutable, any manipulation by an array method affects the array directly. For example,
var fruits = ["mango","banana", "orange"];
fruits.pop();
console.log(fruits) //["mango", "banana"]
The array.pop() method deleted "orange" from the original fruits array.
But with strings for example,
var name = "Donald Trump";
name.replace("Donald", "President");
console.log(name)//Donald Trump
the original string remains intact!
Immutability disallowed any altering of the original string by the string method. Instead, the method produces a new string if the method operation is assigned to a variable like so:
var name = "Donald Trump";
var newName = name.replace("Donald", "President");
console.log(newName);//President Trump
Let's understand here, first,
let firstString = "Tap";
console.log(firstString); //Output: Tap
firstString[0] = "N";
console.log(firstString) //Output: Tap
This is where we can see the immutable effect!
Immutability in this definition is historic. It's attached to what could be done in OTHER programming languages.
I think that is the first thing to understand. And to programmers who have only used JavaScript the question may seem nonsensical or needlessly pedantic. Describing primitives as immutable is like describing ice cream as not being able to jump. Why would I think it could? It is only in relation to other historic programming languages that the lack of mutability is apparent when dealing with primitive types.
I just can't understand how variables are passed, why are some passed by reference while other by value?
Example:
var a=4;
var b=a;
b=b++;
alert(a);//unmodified 4
var c=["t","ttt"];
var d=c;
d=d.sort(function(x,y){return (y.length-x.length);});
alert(c);//modified ["ttt","t"]
Where can I find a list of what variables will work like the first example and which like the second? (booleans, strings, etc... there are too many to test them all by miself)
JavaScript is always pass by value.
It's very common to say that objects in JavaScript are pass by reference, however that is not true. In a true pass by reference language, you could pass a reference to an object's reference, and have it point to another object. This is not possible in JavaScript.
Take, for example, C#. By default everything in C# is pass by value, just like JavaScript.
void foo(string s) {
s = "passbyvalue";
}
string a = "original value";
foo(a);
// a is still "original value"
However, if you alter foo to use pass by reference, the behavior changes:
void foo(ref string s) {
s = "passbyreference";
}
string a = "original value";
foo(ref a);
// a is now "passbyreference"
In JavaScript, only the first example is possible.
In JavaScript, everything is pass by value. This includes the object reference (yes, it is confusing). The reference itself is a value (it's very much like a pointer). It merely contains an id that allows the runtime to look up the object that is most likely stored in its heap. When you pass an object to a function, you are actually copying its reference into the function
It may be a seemingly small, and even anal, difference. But it's a key difference. Languages that have true pass by reference such as C# and C++ allow you to do things that are simply not possible in languages like JavaScript. The above trite example is one.
Imagine everything in JavaScript as an object. Object references are copied by value, but object properties are still used by reference. So:
var a = {};
var b = a;
b = 'Blah';
console.log(a); // Still {}
and
var a = {};
var b = a;
b.test = 'Blah';
console.log(a); // Is now {test: 'Blah'}
To simplify things a little: properties are by reference, values are by value.
Usually you can check the method on MDN. For example, the sort method's documentation states (emphasis added):
Sorts the elements of an array in place and returns the array.
The "in place" there says it will modify the array.
All primitives (for example, numbers and booleans) are passed by value; all objects are passed by reference, although some (like String objects) are immutable (although still passed by reference).
All objects get passed by reference and values by value. (technically this is not true, but it explains the behaviour)
So I was playing around the other day just to see exactly how mass assignment works in JavaScript.
First I tried this example in the console:
a = b = {};
a.foo = 'bar';
console.log(b.foo);
The result was "bar" being displayed in an alert. That is fair enough, a and b are really just aliases to the same object. Then I thought, how could I make this example simpler.
a = b = 'foo';
a = 'bar';
console.log(b);
That is pretty much the same thing, isn't it? Well this time, it returns foo not bar as I would expect from the behaviour of the first example.
Why does this happen?
N.B. This example could be simplified even more with the following code:
a = {};
b = a;
a.foo = 'bar';
console.log(b.foo);
a = 'foo';
b = a;
a = 'bar';
console.log(b);
(I suspect that JavaScript treats primitives such as strings and integers differently to hashes. Hashes return a pointer while "core" primitives return a copy of themselves)
In the first example, you are setting a property of an existing object. In the second example, you are assigning a brand new object.
a = b = {};
a and b are now pointers to the same object. So when you do:
a.foo = 'bar';
It sets b.foo as well since a and b point to the same object.
However!
If you do this instead:
a = 'bar';
you are saying that a points to a different object now. This has no effect on what a pointed to before.
In JavaScript, assigning a variable and assigning a property are 2 different operations. It's best to think of variables as pointers to objects, and when you assign directly to a variable, you are not modifying any objects, merely repointing your variable to a different object.
But assigning a property, like a.foo, will modify the object that a points to. This, of course, also modifies all other references that point to this object simply because they all point to the same object.
Your question has already been satisfyingly answered by Squeegy - it has nothing to do with objects vs. primitives, but with reassignment of variables vs. setting properties in the same referenced object.
There seems to be a lot of confusion about JavaScript types in the answers and comments, so here's a small introduction to JavaScript's type system:
In JavaScript, there are two fundamentally different kinds of values: primitives and objects (and there is no thing like a 'hash').
Strings, numbers and booleans as well as null and undefined are primitives, objects are everything which can have properties. Even arrays and functions are regular objects and therefore can hold arbitrary properties. They just differ in the internal [[Class]] property (functions additionally have a property called [[Call]] and [[Construct]], but hey, that's details).
The reason that primitive values may behave like objects is because of autoboxing, but the primitives themselves can't hold any properties.
Here is an example:
var a = 'quux';
a.foo = 'bar';
document.writeln(a.foo);
This will output undefined: a holds a primitive value, which gets promoted to an object when assigning the property foo. But this new object is immediately discarded, so the value of foo is lost.
Think of it like this:
var a = 'quux';
new String(a).foo = 'bar'; // we never save this new object anywhere!
document.writeln(new String(a).foo); // a completly new object gets created
You're more or less correct except that what you're referring to as a "hash" is actually just shorthand syntax for an Object.
In the first example, a and b both refer to the same object. In the second example, you change a to refer to something else.
here is my version of the answer:
obj = {a:"hello",b:"goodbye"}
x = obj
x.a = "bonjour"
// now obj.a is equal to "bonjour"
// because x has the same reference in memory as obj
// but if I write:
x = {}
x.a = obj.a
x.b = obj.b
x.a = "bonjour"
// now x = {a:"bonjour", b:"goodbye"} and obj = {a:"hello", b:"goodbye"}
// because x points to another place in the memory
You are setting a to point to a new string object, while b keeps pointing to the old string object.
In the first case you change some property of the object contained in the variable, in the second case you assign a new value to the variable. That are fundamentally different things. The variables a and b are not somehow magically linked by the first assignment, they just contain the same object. That's also the case in the second example, until you assign a new value to the b variable.
The difference is between simple types and objects.
Anything that's an object (like an array or a function) is passed by reference.
Anything that's a simple type (like a string or a number) is copied.
I always have a copyArray function handy so I can be sure I'm not creating a bunch of aliases to the same array.