Discussion on: A Collection of JavaScript Tips Based on Common Areas of Confusion or Misunderstanding

[John Wright]

that was really helpful

[pentacular]

Glad to be of help :)

[z2lai]

Woah, that was a lot of elaboration, but in the end it all made sense. Some of the further elaboration did confused me a little though.
For example, you say:

The critical point here is that the value of an object is the object itself, not a copy of the object.

and before that you say:

What you could say is that an object evaluates to a value that holds a reference to the object

So combining these two thoughts: the value of an object is the object itself, which evaluates to a value that holds a reference to the object.
Conceptually, it makes sense to me - the value of an object evaluates to a value that holds a reference to the object - which evaluates to a value that holds a reference to the object - which... But then again, the latter quote forms an infinite loop of logic with itself! What's the term for that...

Personally, I find explaining code in English to be extremely hard because I tend to get into infinite loops of logic.

[pentacular]

I think that you're trying to impose the understanding of JS semantics on top of an assumed implementation model.

Let's imagine that there's a kind of value called an 'object type value'.

And having this 'object type value' lets you access the same set of 'object properties'.

Now, if I pass you my 'object type value' by value, you have an equivalent 'object type value' which lets you access the same 'object properties' that I access using my copy of the 'object type value'.

And the two 'object type values' will compare equal.

And so we can say that these two 'object type values' are the same object.

But actually, the 'object' is in the relationships that the 'object type value' makes available.

We don't need to talk about references or pointers or anything else -- the above is sufficient.

[z2lai]

Hey, thanks for the reply. So what you're saying is that the implementation of 'object type values' being just reference values (pointers) to the memory location containing the object is an assumption rather than a fact? If that's the case, what is the actual implementation? This would be a huge revelation as most educational material online explain the implementation this way.

I'm trying really hard to understand your high level explanation of the implementation but I'm honestly confused because of how high level it is and the new terminology used. For example, you say "when I pass you my 'object type value' by value", that doesn't equate to some code that I can visualize, which forces me to infer that you mean when you assign your 'object type value' to a new variable, but my inference might be wrong. Then you say, "the 'object' is in the relationships". I've never heard of this relationship term used in Javascript before, so I have no idea what that sentence means. Please correct me if I'm wrong and if relationships is an actual term used in the implementation model instead of an abstract concept.

It could just be me though, since I understand explanations much easier from a low level rather than abstract explanations. Ultimately, I think I already understand 'how it works' at a high level and it seems to be the same as what you're explaining (regardless of whether we're using the term relationship or reference). However, I'm inclined to understand how things work under the hood (coming from a math and physics background), which why these high level explanations don't work well with me.

[pentacular]

Let us consider a simple program.

const a = { size: 10 };
const b = a;
const aSize = a.size;
const bSize = b.size;

Now imagine an implementation of Javascript in Javascript, where objects are represented as numbers, and we have Get and Set methods.

We might represent the above like so.

const a = 0;
Set(a, "size", 10);
const b = a;
const aSize = Get(a, "size");
const bSize = Get(b, "size");

The value of the object is its identity, which enables us to access the object's properties.

Sharing this identity allows others to access the same properties.

So we don't need to talk about pointers or references -- we just need the object value and some way to use that to access the object's properties.

There's nothing special about numbers for object values in the example, it might as well have been strings, or dates, or anything that can provide an identity.

As for "under the hood", there isn't any -- unless you're assuming a particular implementation, in which case you're no-longer reasoning about the language, but some particular implementation of it.

If you come from a math background it should be natural to understand things in terms of relationships, rather than mechanics.