66

Javascript passes objects by reference. This makes perfect sense. But once you start manipulating those objects, everything acts in a way that seem unintuitive. Let me offer an example:

var a, b;

a = {}
b = a;
a['one'] = {};

console.log( JSON.stringify(a) );
// outputs: {"one":{}}

console.log( JSON.stringify(b) );
// outputs: {"one":{}}

This is all well and good because now b has a pointer to a so it's expected that assigning stuff to a will also affect b.

But then if I do this:

a = a['one'];

console.log( JSON.stringify(a) );
// outputs: {}

console.log( JSON.stringify(b) );
// outputs: {"one":{}}

This is surprising to me. I'd expect a and b to still be the same (and to be {} since a['one'] was previously set to {} and a was set to a['one']).

But that's not the case. It appears that a loses its reference to b when it's assigned to something new, but b maintains the value that a was set to prior to a loosing its reference to b.

But then if I do this:

a['two'] = 2;

console.log( JSON.stringify(a) );
// outputs: {"two":2}

console.log( JSON.stringify(b) );
// outputs: {"one":{"two":2}}

What? a has clearly lost it's reference to b, but b seems to still have some reference to a.

Does the empty object {} point to some place in memory so every variable referencing it is now pointing to the same place?

Can someone with a firm grasp on this explain it to me?

Philip Walton
  • 29,693
  • 16
  • 60
  • 84
  • See http://stackoverflow.com/questions/518000/is-javascript-a-pass-by-reference-or-pass-by-value-language – Crescent Fresh Nov 29 '11 at 22:15
  • "now `b` has a pointer to `a`" is where the untruth starts. "now `b` points to same place as `a`" is the fix. –  Nov 29 '11 at 22:33
  • 4
    _"Javascript passes objects by reference"_ - No it doesn't. It passes by value but in the case of objects the value passed is a reference to the object and not a copy of the object itself. This is an important distinction. It doesn't really make sense to be talking about "passing" values or references if you're not talking about function parameters, but anyway: if it passed by reference then you could change what object the original variable `a` points to by changing what the second variable `b` points to - which you definitely cannot do (whether in a function or not). – nnnnnn Nov 29 '11 at 22:43
  • @nnnnnn I am confused now. If you assume that Javascript does everything by reference, then how does that lead to being able to change what object `a` points to by changing `b`? It seems that `a` and `b` are references independent of each other, like pointers, and it seems Javascript passes by reference only, it just doesn't pass references to variables, it passes references to what the variables refer to. – Seth Carnegie Nov 29 '11 at 23:00
  • Sorry, no, I said it does _not_ pass by reference, and then said "_if_ it passed by reference" (which it doesn't) _then_ you could change what `a` points to by changing `b` - "which you definitely cannot do". JavaScript does not pass by reference, at all, ever. So you are right that `a` and `b` are like independent pointers that may or may not point to the same object. (But it doesn't make sense to say "pass" unless talking about function params.) – nnnnnn Nov 29 '11 at 23:09
  • @nnnnnn yes I know what you meant. I should have said "if one assumes" instead of "if you assume". So what I meant to ask was, if one assumes that Javascript passes everything by reference instead of by value, I do not see any conflicts in the behaviour of programs to indicate otherwise. If it passed everything by reference (passed a reference to the value to functions) I don't see any inconsistencies. Can you elaborate a little more? Also if you don't @ me I can't tell when you reply. – Seth Carnegie Nov 29 '11 at 23:14
  • @SethCarnegie - A quick example: `function f(b) { b = {}; }` that you call by saying `f(a);` - if the parameter `a` was passed by reference then when the function body assigns `b` to a new object that would change the `a` variable as well. This does _not_ happen in JavaScript. _Other_ languages allow functions to have pass-by-reference parameters, so in those languages similar code to the above would change what `a` points to. That's why I said it doesn't make sense to be talking about "passing" unless talking about function params. – nnnnnn Nov 29 '11 at 23:22
  • @nnnnnn if `f` receives through `b` a reference to whatever `a` was referring to, by doing `b = {}` all you do is make `b` refer to something else. Is what I'm thinking of not called passing by reference? It might be what I mean to say "passing a reference by value" (Also I do not mean passing by reference as C++ does it, it would be passing by pointer there.) – Seth Carnegie Nov 29 '11 at 23:24
  • 1
    @Seth Carnegie: ["Pass by reference"](http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_reference) is a standard non-language-specific programming term that a number of languages support without exposing the programmer to pointers, but JavaScript doesn't do this. What you have said is correct: "passing a reference by value" is what happens with JavaScript objects. My apologies that I didn't manage to say that previously. I think we've been going around in circles due to terminology, sorry. – nnnnnn Nov 29 '11 at 23:48

5 Answers5

209

Following your example line by line:

a = {}

a now references the new object.

b = a;

b now references the same object that a references. Note that it does not reference a.

a['one'] = {};

The new object now has an index 'one' that references another new object.

When you do

a = a['one'];

You are setting a to refer to a['one'], which is that new object you created when you did a['one'] = {}. b still references the object you created with a = {}.

You are confusing the issue when you say "a has lost its reference to b" because a does not refer to b , nor vice versa. a and b refer to objects, and they can be made to refer to other objects. Like this:

With a = {}; b = a, you get

a
 \
  \
   { }
  /
 /
b

Then with a['one'] = {} you get

a
 \
  \
   { one: { } }
  /
 /
b

Then with a = a['one'] you get

a - - - - 
          \
   { one: { } }
  /
 /
b
Seth Carnegie
  • 73,875
  • 22
  • 181
  • 249
  • 4
    Sometimes the simplicity of a = {} loses the clarity of pointers. If it helps, when you read {} in your head replace that with "new object()" and remember that it is creating a new reference. – Will Shaver Nov 29 '11 at 22:11
  • 6
    Awww...epic fail. I post what (I thought) was a great way to explain it then I see this visualization ...*sigh* ... +1. – riwalk Nov 29 '11 at 22:24
47

:P You're descending into the knitty gritty details and I'm glad you asked, as you will be wiser by the end.

Don't look at it in terms of pointers, because I think that is where you are getting confused. Think of it rather in terms of the heap (or just "memory" if you will) and the symbol table.

Lets start by taking the first few lines of your code:

var a, b;

a = {}
b = a;

What you've done here is created one object on the heap and two symbols on the symbol table. It looks something like this:

Symbol Table:

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|      a |        0x400000 |
+--------+-----------------+
|      b |        0x400000 |
+--------+-----------------+

Heap:

+----------+-----------------+
| Location | Value           |
+----------+-----------------+
| 0x400000 | <object val 1>  |
+----------+-----------------+

.

Here's where things get interesting: Objects have their own "symbol tables" (usually these are just hash tables, but calling it a symbol table can make it clearer).

Now, after your next statement, you have 3 things to consider: The global symbol table, <object val 1>'s symbol table, and the heap.

Run the following line:

a['one'] = {}

And now things look like this:

Global Symbol Table:

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|      a |        0x400000 |
+--------+-----------------+
|      b |        0x400000 |
+--------+-----------------+

<object val 1>'s Symbol Table

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|    one |        0x400004 |
+--------+-----------------+

Heap:

+----------+-----------------+
| Location | Value           |
+----------+-----------------+
| 0x400000 | <object val 1>  |
+----------+-----------------+
| 0x400004 | <object val 2>  |     <---we created a new object on the heap
+----------+-----------------+

.

Now you ran the following code:

a = a['one'];

This should hopefully seem to be a trivial change. The result is:

Global Symbol Table:

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|      a |        0x400004 |
+--------+-----------------+
|      b |        0x400000 |
+--------+-----------------+

<object val 1>'s Symbol Table

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|    one |        0x400004 |
+--------+-----------------+

Heap:

+----------+-----------------+
| Location | Value           |
+----------+-----------------+
| 0x400000 | <object val 1>  |
+----------+-----------------+
| 0x400004 | <object val 2>  | 
+----------+-----------------+

.

Following the memory locations to the heap should hopefully make it clear why you got the output you did.

Now things get even MORE interesting, because now you are doing:

a['two'] = 2;

Ok, so let's take this step by step.

  • a points to memory location 0x400004 which contains <object val 2>
  • <object val 2> is an empty object, thus its symbol table starts off empty
  • By running this line, we add the variable 'two' to <object val 2>'s symbol table.

If you're not tired of looking at these diagrams yet, you will be. Things now look like this:

Global Symbol Table:

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|      a |        0x400004 |
+--------+-----------------+
|      b |        0x400000 |
+--------+-----------------+

<object val 1>'s Symbol Table

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|    one |        0x400004 |
+--------+-----------------+

<object val 2>'s Symbol Table

+--------+-----------------+
| Symbol | Memory Location |
+--------+-----------------+
|    two |        0x400008 |
+--------+-----------------+

Heap:

+----------+-----------------+
| Location | Value           |
+----------+-----------------+
| 0x400000 | <object val 1>  |
+----------+-----------------+
| 0x400004 | <object val 2>  | 
+----------+-----------------+
| 0x400008 | 2 (literal val) |    <-- yes, even integers are stored on the heap
+----------+-----------------+        in JavaScript.

.

If you diligently take the time to follow the memory locations, you will see that your browser displayed the correct output.

riwalk
  • 14,033
  • 6
  • 51
  • 68
  • 3
    ha, your diagram is far more detailed than mine (I just do diagrams with arrows). +1 – Seth Carnegie Nov 29 '11 at 22:26
  • 4
    @SethCarnegie, yeah, but you's gets the same point across in far less space. – riwalk Nov 29 '11 at 22:27
  • Is there any kind of tool for displaying JavaScript variable memory locations? Or, otherwise any active way to tinker/debug memory? – P.Brian.Mackey Nov 29 '11 at 22:33
  • 1
    @P.Brian.Mackey...not that I'm aware of. This is a good way to think of it, but modern JavaScript engines optimize to the extreme, so its unlikely that you will be able to have a tool give you a picture exactly like this. (For example: symbol tables are scrapped in favor of offsets whenever possible, and the actual structure of objects can be much more complex using hidden class structures, among other things...its a long rabbit hole...stick to the mental model for now :P) – riwalk Nov 29 '11 at 22:36
9

Think of the anonymous object as itself having a name:

a = {}; // The variable "a" now points to (holds) an anonymous object.
b = a; // "b" points to the same anonymous object held by "a".
a = 123; // "a" now holds some other value.
b; // "b" still holds the anonymous object.

The key is to remember that variables hold references to objects, not references to other variables. And the same object may be referred to by any number of variables.

maerics
  • 151,642
  • 46
  • 269
  • 291
6

Objects in Javascript can exist by themselves without needing a name. For example:

{}

is a new instance of a dictionary object.

a = {};

creates a new dictionary object and makes a refer to it. Now

b = a;

makes b refer to the same underlying object. You can then make a point somewhere else:

a = "hi";

and b still points to the same dictionary object it did before. The behaviour of b is unrelated to how you change what a points to.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
0

As far as i know you overwrited a so i guess the engine saves it in another memory space, whereas b still pointing to the old a's memory address (which somehow doesn't get destroyed).

R01010010
  • 5,670
  • 11
  • 47
  • 77