Code details of function calls in JavaScript

Perhaps many people have encountered confusion about the function parameter transmission method in the process of learning JavaScript. In the spirit of in-depth analysis, I will share with you a tutorial about JavaScript. Function calling knowledge, interested friends can learn together

Definition

Many people may have encountered function parameters in the process of learning Javascript Confused about the transmission method, in the spirit of in-depth analysis, I want to find some answers in the source code. But before doing this, I first need to clarify a few concepts. Abandon the inherent names of value passing, reference passing, etc., and return to English:

call by reference && call by value && call by sharing

They are what we understand as reference passing and value passing in C++. The third one is more confusing. The official explanation is receives the copy of the reference to object . Let me explain it in layman’s terms:

Object can be understood as a collection of key. Object refers to the data pointed to by key (I will not delve into whether it is a pointer implementation or a C++ reference implementation here). What the function receives is a copy of a variable. The variable contains a reference to the Object and is passed by value.

It is obvious that the objecttype parameter we receive when passing function parameters is actually a copy of the actual parameter, so it is not feasible to directly change the pointer of the type parameter; because the Object itself The keys are all references, so it is feasible to modify the key's pointer.

Proof

A few simple pieces of code can prove it

Code 1: The function can modify the data pointed to by key

let func = obj => { obj.name = 'Dosk' };
let obj = {name : 'Alxw'};
console.log(obj); //{ name: 'Alxw' }
func(obj)
console.log(obj); //{ name: 'Dosk' }

Code 2: The function cannot modify obj

let func = obj => { obj = {} };
let obj = {name : 'Alxw'};
console.log(obj); //{ name: 'Alxw' }
func(obj)
console.log(obj); //{ name: 'Alxw' }

Code 3: The internal obj and external === results are equal

let def = {name : 'Alxw'};
let func = obj => { console.log(obj === def) };
func(def); //true

So there may be something wrong with the third piece of code, since obj is a copy of def, why can the === operation still be true? Doesn't it mean that the === operation compares the address in the memory for Object? If it is a copy, it should be false?

So let’s go back to the source code of Google V8 to look at this.

In-depth Google V8

Let’s take a look at the strictly equal operation code part of the source code:

bool Object::StrictEquals(Object* that) {
 if (this->IsNumber()) {
  if (!that->IsNumber()) return false;
  return NumberEquals(this, that);
 } else if (this->IsString()) {
  if (!that->IsString()) return false;
  return String::cast(this)->Equals(String::cast(that));
 } else if (this->IsSimd128Value()) {
  if (!that->IsSimd128Value()) return false;
  return Simd128Value::cast(this)->Equals(Simd128Value::cast(that));
 }
 return this == that;
}

It should look like In the last case, theoretically if def and obj are different objects, then false should be returned. Doesn't this overturn the above? Actually no, one thing is ignored, that is, when instantiating an Object internally, Google V8 itself is a dynamic instantiation, and we know that in compiled languages, dynamic instantiation can only be done on the heap memory, that is, only pointers can be used. Quote. The proof of this conclusion involves the implementation of Local, Handle, etc. class. I think it is too troublesome. There is a simple way to prove it, that is, searchsource code It is found that all calls to Object::StrictEquals are passed in directly without taking the address operation.

However, some people may ask, since the variable passed by value contains a reference to Object, theoretically it can also modify Object. Why can't the third piece of code be modified?

The reason is very simple, because our so-called operations at the logical level of Javascript language are just calling the instance method of Google V8, and it is impossible to operate to this point (of course, potential The BUG is not counted -. -)

##Redefine##I think I can re-explain call by sharing here:

Indeed, the transfer is by value, but the content contains the Object pointer, and this pointer cannot be modified. It is shared by multiple variables.

Another simple proofCome on, look at the source code

V8_DEPRECATE_SOON("Use maybe version",
         Local<Value> Call(Local<Value> recv, int argc,
                  Local<Value> argv[]));
V8_WARN_UNUSED_RESULT MaybeLocal<Value> Call(Local<Context> context,
                       Local<Value> recv, int argc,
                       Local<Value> argv[]);

The above is about to be deprecated

Interface

, it happens that this version of the code I saw contains a lot of this code that is about to be deprecated, just take a look. The focus is on the second interface, which is the only calling interface of the function. The Local will eventually call C++'s bit copy, so it can be simply proved that it is value transfer.

Maybe this is the key pointDon’t forget, the variables we define are similar to

Handle