Are the values of objects the references to them?

# Danny Niu (7 years ago)

I've been struggling finding information on this, so let me open by asking the following question:

Q1: If primitive types are passed by value and objects by reference when calling function, where is this characteristic of objects mentioned in the standard?

I've been trying to find answers from various sources, and I tried asking at stackoverflow.com/questions/45388408 but no result had been satisfactory. People from stackoverflow.com/questions/518000 seems adamant that ES is a pass-by-value language, so I assumed the value of objects are their individuality.

So I tried reasoning a bit further, since it is defined in the standard that objects are a collection of properties, its value must be the uniqueness of such collection. And this makes sense since similar features in other languages also implement objects as reference types.

But is it possible that the standard intentionally left this "implementation-defined"? So here's my second question:

Q2: What's the rationale if any, to not explicitly require that objects be viewed as reference when passed as arguments to functions and assigned to variables.

Thanks.

# T.J. Crowder (7 years ago)

See this recent thread: esdiscuss.org/topic/are-objects-values

As far as I can tell, the answer is the answer Humpty-Dumpty gave Alice: "When I use a word, it means just what I choose it to mean — neither more nor less." :-)

"Value" is used in the spec (AFAICT) to refer to primitive values and objects, and "object reference" isn't mentioned anywhere in the spec. (There's a "Reference" type, but it's used for something else.) The spec's language in this regard is conceptual and I believe in keeping with comp sci high-level theory (Allen Wirfs-Brock is extremely qualified in this regard); but it's also specific enough for implementations to be written unambiguously (usually).

But in other contexts, you might see the term "value" used to refer to the actual thing that variables contain, properties contain, arguments contain, and that are used for the return of a function. In that sense, objects are referenced by values that identify the object (e.g., "object references"). I find this definition useful for reasoning about (and explaining) why when you pass "an object" to a function, the object isn't copied.

But there's another view that even primitives are only referred to, not actually contained, by variables, etc.; just that they're immutable singletons. E.g., that a = 2 would store a reference to 2 in a, not the actual value 2. (And indeed, I expect that's exactly what implementations do with primitive strings.) An implementaton could be written that way and be fully compliant with the spec as far as I know.

Re "pass-by-value" vs. "pass-by-reference" - it has nothing to do with object references at all. The word "reference" is used for many different things. In that case, pass-by-reference is a term of art meaning that in, say, foo(bar), foo gets a reference to the variable bar that's passed in and can change bar's contents. JavaScript doesn't have that.

HTH,

-- T.J. Crowder

# Allen Wirfs-Brock (7 years ago)

On Aug 26, 2017, at 2:56 AM, T.J. Crowder <tj.crowder at farsightsoftware.com> wrote:

The spec's language in this regard is conceptual and I believe in keeping with comp sci high-level theory (Allen Wirfs-Brock is extremely qualified in this regard); but it's also specific enough for implementations to be written unambiguously (usually).

Actually, that terminology was introduced by the first edition of ECMA-262 in 1997. Guy Steele was the editor for ES1 and I happily defer to his terminology choices.

# Michael Dyck (7 years ago)

On 2017-08-26 05:40 AM, Danny Niu wrote:

Hi all, I've been struggling finding information on this, so let me open by asking the following question:

Q1: If primitive types are passed by value and objects by reference when calling function, where is this characteristic of objects mentioned in the standard?

Objects aren't "passed by reference" according to the original/usual sense of that term.

People from stackoverflow.com/questions/518000 seems adamant that ES is a pass-by-value language, so I assumed the value of objects are their individuality.

The top two answers there both say (more or less) it's pass-by-value, and for objects, the 'value' is a reference to the object.

So you might wonder why objects are special in this regard. But they aren't: if you like, you can imagine everything being passed by value, where the 'value' is a reference to the thing.

Q2: What's the rationale if any, to not explicitly require that objects be viewed as reference when passed as arguments to functions and assigned to variables.

One reason might be to avoid confusion with the Reference type. Another reason might be to avoid making a distinction that the spec will never (or rarely) use.

When you pass a value to a function-parameter or assign a value to a variable, you are (in spec terms, more or less) binding that value to an identifier name, i.e., creating an association between the name and the value.

Given that terminology, I don't think it helps to add "reference" to the description. It's enough to understand that a value can participate in multiple bindings/associations at the same time. But you're free to imagine references being involved in the implementation.

# Allen Wirfs-Brock (7 years ago)

this…

# Jordan Harband (7 years ago)

Things in JS are passed (to functions) by value, because direct assignment to the binding isn't visible outside the function (take no note of sloppy-mode arguments over there behind the curtain. ES Module live-bindings of exports add a wrinkle, as well)

I've found web.archive.org/web/20161005155047/http://www.jon-carlos.com/2013/is-javascript-call-by-value-or-call-by-reference helpful.

# T.J. Crowder (7 years ago)

On Sat, Aug 26, 2017 at 4:57 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

Actually, that terminology was introduced by the first edition of ECMA-262 in 1997. Guy Steele was the editor for ES1 and I happily defer to his terminology choices.

Let's just say I was trusting that as primary editor for the last several versions, you'd've fixed it if it were incorrect in some way. :-)

On Sat, Aug 26, 2017 at 9:41 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

this…

On Aug 26, 2017, at 1:26 PM, Michael Dyck <jmdyck at ibiblio.org> wrote:

Anotherreason might be to avoid making a distinction that the spec will never (or rarely) use.

When you pass a value to a function-parameter or assign a value to a variable, you are (in spec terms, more or less) binding that value to an identifier name, i.e., creating an association between the name and the value.

Given that terminology, I don't think it helps to add "reference" to the description. It's enough to understand that a value can participate in multiple bindings/associations at the same time. But you're free to imagine references being involved in the implementation.

Thank you Michael and Allen. This is exactly the kind of answer I was looking for when I asked my question a couple of weeks ago. Vis-à-vis that, when helping beginners understand object references, I'll keep using the terminology I've been using (whew) but make sure they understand "value" can be and is used in other ways, notably in the spec.

-- T.J. Crowder