Well yea, you are kind of comparing apples with pears.
The same thing would happen without the function. For the reference to not break, you cannot reassign p - only it's properties.
leta={v:1};constfoo=(p)=>{p.v=2};foo(a);console.log(a);// prints { v: 2 }
.. this would still be a reference and mutate a.
Same gist, but without the function
letc={someText:"Hello"}letd=c;d={v:2}console.log(c);// prints { someText: "Hello" }
In this code it acts like you passed the memory location foo(#234)
when you change it with p = { v: 2 }; you're creating entire new object { v: 2 } this objects has a new memory location like #427, you're changing value #234 with #427 so a is also changing
Edit: value of a is not changing
leta={v:1}functionchangeValue(x){x={v:2}// you're not really changing value of a you're changing value of x which is reference to value of a }changeValue(a)a// { v: 1 }
a changes when you change property of a in function
leta={v:1}functionchangeProp(x){x.v=2// a is also changing because by changing property you're not changing reference to `{ v: 1 }`, you're changing value inside that reference}changeProp(a)a// { v: 2 }
Again, you reassign the variable. That is indeed pass-by-value but only because you reassign the variable, which in any case you shouldn't do because it's semantically confusing.
Have a look at the style guide by AirBnB for example on this topic (github.com/airbnb/javascript#es6-d...)
In other words (not mine):
if your value is an object, then the new scope gets a copy of the reference. If you modify the object by dereferencing (that is, a.foo = "bar";), your modifications to the object persist outside of your scope.
Your change does not persist outside of the function-scope because you did not mutate the original reference to a. You created a "temporary" version of it inside the function, which doesn't exist anymore because of the function scope. If you want the change to persist (pass-by-ref), you have to dereference it (look at my earlier example).
Coding since 11yo, that makes it over 30 years now ~~~
Have a PhD in Comp Sci ~~~
Love to go on bike tours ~~~
I try to stay as generalist as I can in this crazy wide place coding is at now.
consta=somethingfunctionfoo(value){codez}foo(a)// <= this could never change the type of a, since foo never sees a itself, just its valuefunctionbar(pram){pram.baz=1// <= this isn't mutating pram, but the details of the object pram refers to.pram=1// <= this mutates pram itself. Were it pass-by-reference then the argument to the function in the caller scope would now read as 1, because it's the thing we just set to 1}
But, the "value" of a variable for a JS object is a reference to the underlying object.
This is the same with strings, but they're immutable so their references cause less confusion
consta="hi"constb="hi"// a and b are two values that refer to the one common string in memorya="bye"// reassigning a doesn't change b
So, functions pass by value, but in many cases that value is just a reference to some common structure.
Hey man, just some feedback on your conversational style:
I find it's quite confrontational and irritating to read.
To me it feels like your trying to score internet points for being right and aren't actually interested in explaining things to people.
It reads more like a Twitter or Reddit thread and I was always very happy to see a calmer more constructive and friendly style on here.
I really don't mean this as a personal attack, I just feel the conversation could have a lot more merit to others (especially newcomers) if it were more constructive.
Coding since 11yo, that makes it over 30 years now ~~~
Have a PhD in Comp Sci ~~~
Love to go on bike tours ~~~
I try to stay as generalist as I can in this crazy wide place coding is at now.
I'm glad we can all agree that javascript doesn't support pass by reference.
Now, could you show me where in the ecmascript standard it talks about an object value being a reference?
vvvvvv
(First para deleted)
What do you mean that object values are references? I've been fishing through the spec (ecma-international.org/ecma-262/11...) and can't find anything saying so.
Same info and questions, but the second one is showing you're willing to put in some work to find your answer, that we probably fundamentally agree but are stuck on terminology, and will ultimately avoid nag replies like this.
If the language doesn't come naturally to you, try your best to fake it til you make it.
I had a squiz at the spec, couldn't find a specific mention, and ran out of motivation to dig further. The proof though is
a={}b=aa.foo=1console.log(b.foo)// <- prints "1"
For a time, the values of a and brefer to the same object. They hold two pointer-like structures that reference the same shared underlying object. In programming this is often called a reference.
Coding since 11yo, that makes it over 30 years now ~~~
Have a PhD in Comp Sci ~~~
Love to go on bike tours ~~~
I try to stay as generalist as I can in this crazy wide place coding is at now.
That's fine, but for future reference, let's note that a.foo doesn't mean that a is a reference.
It does mean that a and b have the same value, and it does mean that that value is used to find a particular property named 'foo' and modify that.
Which makes me think that all of this 'reference' stuff is something someone made up to try to explain javascript in terms of a language with references, like C++, but which doesn't quite fit.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Try now ;)
Well yea, you are kind of comparing apples with pears.
The same thing would happen without the function. For the reference to not break, you cannot reassign
p
- only it's properties... this would still be a reference and mutate a.
Same gist, but without the function
Yeah, when you assigning
{ v: 2 }
to p you're actually changing value of p with completely new one, this diagram can be helpfulWhen you changed value of p with
p = { v: 2 };
it becomes like thismemory location #234 will be inaccessible and garbage collected, I hope this helps
So.
Pass by value, then? :)
Can you take a look in the ecmascript spec and show me where it talks about a being a reference?
I can only see it referring to object values.
Not exactly think it like this
in this code you pass the value of the a and it acts like
addHi("Hello")
so you're not changing the a
In this code it acts like you passed the memory location
foo(#234)
when you change it with
p = { v: 2 };
you're creating entire new object{ v: 2 }
this objects has a new memory location like #427, you're changing value #234 with #427so a is also changingEdit: value of a is not changing
a changes when you change property of a in function
When I run
the output is
I don't see a changing.
So, which bit of this isn't just pass-by-value in both cases?
Again, you reassign the variable. That is indeed pass-by-value but only because you reassign the variable, which in any case you shouldn't do because it's semantically confusing.
Have a look at the style guide by AirBnB for example on this topic (github.com/airbnb/javascript#es6-d...)
In other words (not mine):
Your change does not persist outside of the function-scope because you did not mutate the original reference to
a
. You created a "temporary" version of it inside the function, which doesn't exist anymore because of the function scope. If you want the change to persist (pass-by-ref), you have to dereference it (look at my earlier example).Ok, so we can all agree that it is pass by value.
And that there is no pass by reference happening anywhere here.
Which means that what we're passing is the value of the object.
All well and good.
Can you show me where it says that object values are references, in the ecmascript standard?
I'm having trouble finding support for that claim.
JS always passes function args by value.
But, the "value" of a variable for a JS object is a reference to the underlying object.
This is the same with strings, but they're immutable so their references cause less confusion
So, functions pass by value, but in many cases that value is just a reference to some common structure.
I'm glad we can all agree that javascript doesn't support pass by reference.
Now, could you show me where in the ecmascript standard it talks about an object value being a reference?
Hey man, just some feedback on your conversational style:
I find it's quite confrontational and irritating to read.
To me it feels like your trying to score internet points for being right and aren't actually interested in explaining things to people.
It reads more like a Twitter or Reddit thread and I was always very happy to see a calmer more constructive and friendly style on here.
I really don't mean this as a personal attack, I just feel the conversation could have a lot more merit to others (especially newcomers) if it were more constructive.
Could you be more specific about the confrontational style that you perceive?
A bit of constructive editing...
vvvvvv
Same info and questions, but the second one is showing you're willing to put in some work to find your answer, that we probably fundamentally agree but are stuck on terminology, and will ultimately avoid nag replies like this.
If the language doesn't come naturally to you, try your best to fake it til you make it.
I had a squiz at the spec, couldn't find a specific mention, and ran out of motivation to dig further. The proof though is
For a time, the values of
a
andb
refer to the same object. They hold two pointer-like structures that reference the same shared underlying object. In programming this is often called a reference.I'm signing off the thread btw
That's fine, but for future reference, let's note that a.foo doesn't mean that a is a reference.
It does mean that a and b have the same value, and it does mean that that value is used to find a particular property named 'foo' and modify that.
Which makes me think that all of this 'reference' stuff is something someone made up to try to explain javascript in terms of a language with references, like C++, but which doesn't quite fit.