How to explain object references in ECMAScript terms?

Question

Consider this:

var a = {}, b = a;

In terms of the spec, b = a boils down to PutValue(b, GetValue(a)), right? And GetValue(a) uses GetBindingValue("a", strictFlag) abstract operation, which returns "the value" in a. And "the value" is "the object" originally assigned to a. Then "the object" is stored in b, just like any other value would.

But what is "the object" precisely? Where does the specification say that values of the Object type behave differently than primitives? Is it only that primitives are immutable, and objects are mutable?

I'm asking because we always talk about "object references" and "reference values" when trying to explain the behavior of objects, but I couldn't find anything analogous to that in the specification.

Answer 1

Where does the specification say that values of the Object type behave differently than primitives? Is it only that primitives are immutable, and objects are mutable?

Yes, it basically boils down to the mutability of objects, and the identity of objects. Actually, this is not even specified anywhere, it is just assumed as a given core idea of object-oriented programming. The only mention of it is a comment in the Annex E, which states that "the change [of regex literal expression values] is detectable by any programs that test the object identity of such literal values or that are sensitive to the shared side effects".

Even the mutability of objects in nowhere explicitly stated, but implied by phrases as "In ECMAScript, the state and methods are carried by objects", "An ECMAScript object is a collection of properties" and several notions of "changing" property values, "creating" properties or "setting" property attributes (in the [[DefineOwnProperty]] method).

Update: PR#2821 is going to introduce the concept of identity and describe objects as mutable. It may land in ES2023 :-)

I'm asking because we always talk about "object references" and "reference values" when trying to explain the behaviour of objects, but I couldn't find anything analogous to that in the specification.

That's because the spec is not a guide to the language, and an explanation of its features, but merely a specification of its (inner) characteristics. The reader is expected to know OOP and its ideas.

In fact, the language always talks of values only - regardless whether that may be primitive values or objects. The only things that can be mutated by the tools of the language are the binding of Environment Records (variables) and the properties Objects, everything else (including object identity) is implicitly considered immutable.

When we try to explain the "behaviour of objects", we basically explain the concept of the identity of objects. Usually the audience is coming from lower-level, non-OOP languages, where assignments do copy by default, and sharing values is done by pointers (references). To them, we explain objects as a "reference to the collection of properties", and all appearances of an object are references that point to the same collection. There is no builtin way to copy the collection.

However, to emphasise the lack of references in general¹ (one cannot make a reference to an identifier binding, i.e. a variable - regardless of it's value's type) and to conform with the official phrasing, we also use the term value for everything. This coined the term "reference value" for objects.

Also, the wording in the Sameness/Equality Algorithm(s) matches this: "where x and y are values, …, [when both are of type Object], …, return true if x and y refer to the same object."

---

_{1. Actually, the spec describes References as a Specification Type. They do denote properties of objects, and are used to describe the behaviour of delete, property assignments, method calls etc. They however cannot be passed around (assignment, function call), are internal only and not obtainable, and will not point to variables. Still, there is no builtin way to acquire some kind of pointer to a local variable.}