1. ReturnIfAbrupt(V).
2. If Type(V) is not Reference, return V.
3. Let base be GetBase(V).
4. If IsUnresolvableReference(V) is true, throw a ReferenceError exception.
5. If IsPropertyReference(V) is true, then
a. If HasPrimitiveBase(V) is true, then
i. Assert: In this case, base will never be undefined or null.
ii. Set base to ! ToObject(base).
b. Return ? base.[[Get]](GetReferencedName(V), GetThisValue(V)).
6. Else,
a. Assert: base is an Environment Record.
b. Return ? base.GetBindingValue(GetReferencedName(V), IsStrictReference(V)) (see 8.1.1).
I'm not seeing the relevant distinction -- could you point it out?
If you do a behavior test in any interpreter there is obviously a difference. I'm pretty sure not every JS interpreter developer is mistaken. There is a clear difference but we've gone from me saying "hey, that's not a deep copy" to you asking me to point out the intricacies of the JS spec. Sorry, read it again. Every JS interpreter dev can't be wrong and you're right.
You're moving the goal posts. I said it distinguishes between an object and primitives. That is demonstrated by the example in my first comment, which is why it's not a deep copy. Every interpreter runs my example the same way, allowing you to mutate the original using the copy.
Every interpreter since I started writing JS in the 1990s treats objects and primitives differently. There are countless articles over the last 20 years about that fact. You can't really believe that everyone is wrong. Given that, it must be you who misunderstands the spec. So I suggest you look up all the definitions of things used inside GetValue. If you look at it long enough, you'll see that it quite clearly follows a different path for primitive values than it does for objects.
I'm not seeing the relevant distinction -- could you point it out?
No, I'm not going to read the spec for you.
I did the reading.
There's nothing there that distinguishes between primitive and object values.
So, I think you're mistaken and am giving you the opportunity to reconsider your claim.
If you do a behavior test in any interpreter there is obviously a difference. I'm pretty sure not every JS interpreter developer is mistaken. There is a clear difference but we've gone from me saying "hey, that's not a deep copy" to you asking me to point out the intricacies of the JS spec. Sorry, read it again. Every JS interpreter dev can't be wrong and you're right.
What is the obvious difference?
Every JS interpreter I've used copies the value of the object exactly as I expect, given my understanding of the spec.
Noting that the spec differentiates between an object value and the properties associated with that object value.
Please clarify the behavior test that you have in mind so that it can be tested.
You're moving the goal posts. I said it distinguishes between an object and primitives. That is demonstrated by the example in my first comment, which is why it's not a deep copy. Every interpreter runs my example the same way, allowing you to mutate the original using the copy.
Every interpreter since I started writing JS in the 1990s treats objects and primitives differently. There are countless articles over the last 20 years about that fact. You can't really believe that everyone is wrong. Given that, it must be you who misunderstands the spec. So I suggest you look up all the definitions of things used inside GetValue. If you look at it long enough, you'll see that it quite clearly follows a different path for primitive values than it does for objects.
What's the distinction that it makes?
JS doesn't allow you to mutate values at all -- and there's no difference between objects and values in that regard.
The only things you can mutate in JS are properties and variables.
(And this is one of the reasons that properties are not part of the object's value)
Objects and primitives have their values copied when the assignment sign is used. Primitive values are literal values, object values are pointers.