Javascript pointer/reference craziness. Can someone explain this?

JavascriptPointersReference

Javascript Problem Overview


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?

Javascript Solutions


Solution 1 - Javascript

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

Solution 2 - Javascript

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

Solution 3 - Javascript

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.

Solution 4 - Javascript

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.

Solution 5 - Javascript

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

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionPhilip WaltonView Question on Stackoverflow
Solution 1 - JavascriptSeth CarnegieView Answer on Stackoverflow
Solution 2 - JavascriptriwalkView Answer on Stackoverflow
Solution 3 - JavascriptmaericsView Answer on Stackoverflow
Solution 4 - JavascriptGreg HewgillView Answer on Stackoverflow
Solution 5 - JavascriptR01010010View Answer on Stackoverflow