4. References: two names, one object

A puzzle

Predict what each of these prints before you read on:

let m = 1;
let n = m;
n = 99;
console.log(m);

const a = { x: 1 };
const b = a;
b.x = 99;
console.log(a.x);

The first prints 1. Changing n didn’t touch m. The second prints 99. Changing b did change a. Same-looking code, opposite results. Why?

The arrows

Step through it. On the left are the variables; on the right, the objects living in memory.

const a = { x: 1 };
const b = a;
b.x = 99;
console.log(a.x);
const c = { x: 99 };
console.log(a === b);
console.log(a === c);

This also solves a mystery from chapter 2: how can you push onto a const array? const freezes the arrow: the name can never point at a different array. It says nothing about the array the arrow points at, and that array can still be changed.

Arrays are objects too

Everything above holds for arrays, because arrays are objects:

const list = [1, 2, 3];
const same = list;
same.push(4);

console.log(list);         // [ 1, 2, 3, 4 ]
console.log(list === same); // true
console.log([1] === [1]);   // false

Two separately written [1]s are two different arrays, so === says false even though they look identical.

const a = { x: 1 };
const b = a;
b.x = 99;
console.log(a.x);

const c = { x: 99 };
console.log(a === b, a === c);

const list = [1, 2];
const same = list;
same.push(3);
console.log(list);

Functions get arrows too

When you pass an object to a function, the parameter receives a copy of the arrow. Function and caller now share one object:

function birthday(person) {
  person.age = person.age + 1;
}

const ada = { name: 'Ada', age: 36 };
birthday(ada);
console.log(ada.age); // 37

That’s why step(particles) in the last chapter could move the caller’s particles without returning anything. But notice what a function can’t do: point the caller’s variable somewhere else.

function replace(person) {
  person = { name: 'Bob', age: 1 };
}

replace(ada);
console.log(ada.name); // Ada

person = ... re-aims only the function’s own local copy of the arrow. The caller’s ada arrow never moved.

Making a real copy

Sometimes you want a separate object. Spread syntax, {...obj}, builds a brand-new object and copies the properties into it:

const p = { x: 1, y: 2 };
const q = { ...p, x: 50 };

console.log(p.x);    // 1
console.log(q.x);    // 50
console.log(p === q); // false

Properties listed after the spread override the copied ones, so { ...p, x: 50 } means “a copy of p, but with x set to 50”.

Why this is Viscosity’s hardest problem

Remember the particle loop. Suppose Viscosity decides your particles would be faster as a struct of arrays: one array of all the x values, one of all the y values. Now look at this ordinary code:

const first = particles[0];
first.x = 100;
console.log(particles[0].x); // must be 100

first and particles[0] are aliases. They’re the same object, and the program relies on that. If Viscosity had quietly moved x into a separate array, first.x = 100 would have to update that array too. Otherwise the program prints the wrong answer, and an optimizer that changes answers is worse than no optimizer at all.

So before it can change how data is laid out, Viscosity has to answer: where can arrows to these objects end up? Who else might be looking at them? Compilers call this alias analysis and escape analysis, and they’re what make automatic layout changes safe. Research systems that switch JavaScript arrays to columns automatically face exactly this requirement^[3]. You’ll build these analyses yourself in Parts VI and VII. For now, you can see the problem, and that’s the first step to solving it.

Your turn

function withX(p, x) {
  // your code here
}

const p = { x: 1, y: 2 };
const q = withX(p, 9);
console.log(p, q);

function indexOfSame(xs, target) {
  // your code here
}

const a = { id: 1 };
const xs = [{ id: 1 }, a];
console.log(indexOfSame(xs, a));

What you learned

• A variable holding an object holds a reference: an arrow, not the object.
• Copying the variable copies the arrow. Two arrows to one object are aliases, and a mutation through either is seen by both.
• === on objects compares identity: same object, not same contents.
• Functions receive arrows, so they can mutate the caller’s objects, but they can’t re-aim the caller’s variables.
• { ...obj } makes a new, shallow copy.
• Aliasing is why changing data layout automatically is hard. It is the problem at the core of Viscosity.

That’s the end of Day 1. Tomorrow: functions as values, and closures.