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
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).
: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<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.
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
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.
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.