Some blogs say that the literal(or basic data type?) can’t be changed. So I think A is wrong.
The code b=20 doesn’t declare a new variable. It is just a reassignment of b. So B may not suitable.
For the answer C, a basic data type variable is also a pointer though the variable and value stored together in stack. So can we say the basic data type is similar to the reference data type which illustrated in the following picture in some degree?
I believe that it is in fact a.(Edit: conceptually and effectively it works like this, but not internally in the JS engine) A variable holds either a primitive data type value or a reference to an object. The contents are not changed, but they are replaced.
I do not believe that you have any access to raw memory management functionality in JS, to include memory addresses. This is a good thing.
Hmm, now I’m second guessing myself At first I thought that A was correct. But primitives are immutable, their value cannot be changed. You can definitely reassign a variable with a new primitive, but I believe the original primitive value doesn’t change. So I’m tempted to think that A is not the answer.
As for whether B or C is correct, I guess I’m not sure what the red arrows are supposed to represent? As you noted, underneath the hood, a variable really stores a pointer to a location in memory. Are the red arrows representing actual memory pointers? If so, then I guess I would go with C. Or are they representing JS “references” such as when a JS variable stores an object (which is really a reference/pointer to another memory address)? If so then I would go with B.
In JS, when I think of a primitive value being stored on the stack, I don’t think of it as a variable storing a pointer to a memory address that holds the actual value. I cut out the middle man and just think of it as the variable stores the actual value itself. Since we can’t get the actual memory address of a variable in JS, I don’t see any reason to have to think of it in terms of memory pointers. If a variable stores an object then I think of it as the variable stores a “reference” to the object, which I know is technically a pointer to a memory location, but again, we don’t deal with pointers in JS so I’m fine thinking of it as a “reference”. My point here is that for primitives I think of them as what is represented in B.
I think to really answer this, you need to stop trying to think about JS and actually think about the JS engine.
And I think this may come down to implementation decisions in the JS engine.
For the V8 engine, it looks like there are ‘value’ objects and ‘variable’ objects that get bound together in ‘scope’ objects in a variable hash map. I have no idea if B or C is supposed to represent this. And I have no idea how different engines decide to model this.
But I really don’t think that any of this helps us ‘use’ JS any better.
To me, it is most useful to think of JS variables as always holding a single value, and that single value is either a single primitive value or the location of a more complex multi-valued object. Then we can either change the primitive value we are using or we can change which complex multi-valued object we are referencing.
The whole point is to hide the memory management from the user, so understanding how the primitive and object reference values are implemented inside of the engine isn’t really useful. But it can be interesting I suppose.
At first I thought that A was correct. But primitives are immutable, their value cannot be changed. You can definitely reassign a variable with a new primitive, but I believe the original primitive value doesn’t change. So I’m tempted to think that A is not the answer.