JavaScript does not contain pointers, which are the "reference" in pass by reference, but for objects it has the same impact as pass-by-reference... non-primitive values can be mutated.
Apparently this is called pass-by-sharing, though it is not something that I would think to call it.
I think of it as abstracted pass-by-reference. A variable or property which is not a primitive ultimately does have a pointer at a lower level than the language provides. Accessing or mutating the object is accomplished through that hidden reference; we just don't get to see it. If you reassign the parameter, you replace the reference, so the original object from outside the scope is inaccessible.
This essentially follows the description of pass-by-sharing...certain there are certain types that use a reference to share an object.
There's been lots of attempts at coming up with new words for the combination of call-by-value and reference types, but at the end of the day, those are still, strictly speaking, call-by-value. The value being a reference to some other data that may or may not be mutable.
It's also only half true that JavaScript doesn't have pointers. Pointers are a low-level construct that represents a reference to some data via its memory location as a number, so you can do some degree of arithmetic on them. JavaScript abstracts these internals away, but still gives us references to objects that, internally, use pointers. We can't do arithmetic on these references, but they still can do other things pointers can do, like being passed into a function to be mutated.
As for primitives, since they are all immutable in JavaScript, there isn't really a meaningful distinction between how they are shared. Internally, the VM probably shares at least strings by reference, and might do the same for larger numbers.
If we think of, say, the integer 20 as an instance of some immutable number class, where all operations on it create a new instance, and calling a function with it passes a reference to said number as an argument, then we can still expect it to behave the exact same way as if we think of it as a plain integer that gets copied into whatever memory the function uses.
This is why I think concepts like "pass-by-sharing" are somewhat missing the point: They tell us only about the values we're dealing with and their types, whereas the actual "call-by-reference" / "call-by-value" distinction tells us something about the variables holding the values.
In call-by-reference, the function isn't called on the value itself, but on the variable. If we assign a new primitive value to the function argument, the actual variable outside of it will be changed accordingly. Internally this will likely be implemented by some sort of reference type, but if a subroutine is inlined, then it may well not be. Either way, that's an implementation detail that shouldn't be paid much attention when talking about conceptual language features.
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.
JavaScript does not contain pointers, which are the "reference" in pass by reference, but for objects it has the same impact as pass-by-reference... non-primitive values can be mutated.
Apparently this is called pass-by-sharing, though it is not something that I would think to call it.
I think of it as abstracted pass-by-reference. A variable or property which is not a primitive ultimately does have a pointer at a lower level than the language provides. Accessing or mutating the object is accomplished through that hidden reference; we just don't get to see it. If you reassign the parameter, you replace the reference, so the original object from outside the scope is inaccessible.
This essentially follows the description of pass-by-sharing...certain there are certain types that use a reference to share an object.
There's been lots of attempts at coming up with new words for the combination of call-by-value and reference types, but at the end of the day, those are still, strictly speaking, call-by-value. The value being a reference to some other data that may or may not be mutable.
It's also only half true that JavaScript doesn't have pointers. Pointers are a low-level construct that represents a reference to some data via its memory location as a number, so you can do some degree of arithmetic on them. JavaScript abstracts these internals away, but still gives us references to objects that, internally, use pointers. We can't do arithmetic on these references, but they still can do other things pointers can do, like being passed into a function to be mutated.
As for primitives, since they are all immutable in JavaScript, there isn't really a meaningful distinction between how they are shared. Internally, the VM probably shares at least strings by reference, and might do the same for larger numbers.
If we think of, say, the integer
20as an instance of some immutable number class, where all operations on it create a new instance, and calling a function with it passes a reference to said number as an argument, then we can still expect it to behave the exact same way as if we think of it as a plain integer that gets copied into whatever memory the function uses.This is why I think concepts like "pass-by-sharing" are somewhat missing the point: They tell us only about the values we're dealing with and their types, whereas the actual "call-by-reference" / "call-by-value" distinction tells us something about the variables holding the values.
In call-by-reference, the function isn't called on the value itself, but on the variable. If we assign a new primitive value to the function argument, the actual variable outside of it will be changed accordingly. Internally this will likely be implemented by some sort of reference type, but if a subroutine is inlined, then it may well not be. Either way, that's an implementation detail that shouldn't be paid much attention when talking about conceptual language features.