Deep understanding of JavaScript Series (19): Evaluation Strategy (Evaluation Strategy) Details _ Basics

Introduced

In this chapter, we will explain the policy of passing arguments to function functions in ECMAScript.

In computer science, this strategy is commonly referred to as "evaluation strategy" (Uncle Note: Some people say that translation into the evaluation strategy, some people translated into assignment strategy, see the following content, I think the assignment strategy is more appropriate, anyway, The title is written as an easy to understand evaluation strategy, such as setting a rule in a programming language for evaluating or evaluating an expression. The policy of passing parameters to a function is a special case.

http://dmitrysoshnikov.com/ecmascript/chapter-8-evaluation-strategy/
The reason for writing this article is because some people on the forum asked to explain some of the parameters of the strategy, we have given a corresponding definition, we hope to be helpful.

Many programmers are convinced that in JavaScript (or even some other language), objects are referenced by reference, and that the original value type is passed by value, and that many articles refer to the "fact", but how many people really understand the term and how much is true? We'll explain this one by one.

General theory

It should be noted that in the assignment theory there are generally 2 assignment strategies: strict--meaning that the parameters are computed before entry into the program, not strictly--meaning that the calculation of the parameters is calculated on the basis of the computational requirements (that is, the equivalent of the deferred computation).

Then, here we consider the basic function argument strategy, which is very important from the ECMAScript starting point. The first thing to note is that strict parameter-passing policies are used in ECMAScript (and even in other languages such as C,java,python and Ruby).

It is also important to calculate the order in which the parameters are passed--the ECMAScript is left to right, and the sequence of introspection that other languages implement (from the right) is also available.

Strict communication strategy is also divided into several seed strategies, the most important of which we discussed in detail in this chapter.

Not all of the strategies discussed below are used in ECMAScript, so when we discuss the specific behavior of these strategies, we use pseudo code to show them.

Pass by value

Passed by value, and many developers know it, the value of the parameter is a copy of the object value passed by the caller (copy of value), which changes the value of the parameter within the function without affecting the outside object (the value outside the parameter) and, in general, the new memory is reassigned (we are not concerned about how the allocated memory is implemented- -It is also a stack, perhaps a dynamic memory allocation, where the value of the new memory block is a copy of the external object, and its value is used inside the function.

Copy Code code as follows:

Bar = 10

Procedure Foo (BARARG):
Bararg = 20;
End

Foo (BAR)

Foo Internal change value does not affect the value of bar inside
Print (bar)//10

However, if the function's arguments are not raw values but complex structural objects, then there is a significant performance problem, and C + + has this problem, when the structure is passed into the function as a value-the full copy.

Let's give a general example to test with the following assignment strategy, think about it. A function accepts 2 arguments, the 1th argument is the value of the object, and the 2nd is a Boolean tag that marks whether to completely modify the incoming object (to reassign the object), or to modify only some of the object's properties.

Copy Code code as follows:

Note: The following are pseudo code, not JS implementation
Bar = {
X:10,
Y:20
}

Procedure foo (Bararg, Isfullchange):

If Isfullchange:
Bararg = {z:1, q:2}
Exit
End

bararg.x = 100
BARARG.Y = 200

End

Foo (BAR)

Passed by value, external objects are not changed
Print (bar)//{x:10, y:20}

Completely Alter object (assign new value)
Foo (bar, True)

There's no change.
Print (bar)//{x:10, y:20}, not {z:1, q:2}

Passing by reference

Another well-known pass-by-reference is not a value copy, but an implicit reference to an object, such as an external direct reference address for that object. Any change in the parameters within a function affects the value of the object outside the function because both refer to the same object, which means that the argument is the equivalent of an alias to an external object.

Pseudo code:

Copy Code code as follows:

Procedure foo (Bararg, Isfullchange):

If Isfullchange:
Bararg = {z:1, q:2}
Exit
End

bararg.x = 100
BARARG.Y = 200

End

Use the same object as the previous example
Bar = {
X:10,
Y:20
}

The results called by reference are as follows:
Foo (BAR)

The property value of the object has been changed
Print (bar)//{x:100, y:200}

Re-assigning new values also affects the object
Foo (bar, True)

Now the object is already a new object.
Print (bar)//{z:1, q:2}

This strategy enables more efficient delivery of complex objects, such as large structure objects with large batch attributes.

Deliver by share (call by sharing)
the above 2 strategies are known to all, but a strategy here may not be known (in fact, an academic strategy). However, we will soon see that this is the strategy that plays a key role in ECMAScript's parameter-passing strategy.

This strategy also has some pronouns: "pass by object" or "Share by object".

The strategy was proposed in 1974 by Barbara Liskov for the CLU programming language.

The point of this strategy is that the function receives the copy (copy) of the object for which the reference copy is associated with the formal parameter and its value.

The reference that appears here cannot be called "by reference" because the parameter received by the function is not a direct object alias, but a copy of the reference address.

The most important difference is that a function that assigns a new value to a parameter does not affect the external object (and the case that is passed by reference in the previous example). But because the parameter is a copy of the address, both the outside access and the inside access are the same object (for example, the external object is not a complete copy to be passed by value), Changing the property value of the Parameter object will affect the external object.

Copy Code code as follows:

Procedure foo (Bararg, Isfullchange):

If Isfullchange:
Bararg = {z:1, q:2}
Exit
End

bararg.x = 100
BARARG.Y = 200

End

Or use this object structure
Bar = {
X:10,
Y:20
}

Delivery by contribution will affect the object
Foo (BAR)

The object's properties have been modified
Print (bar)//{x:100, y:200}

Re-assignment does not work
Foo (bar, True)

is still the value of the above
Print (bar)//{x:100, y:200}

This processing assumes that the object used in most languages is not the original value.

Passing by share is a special case of passing by value

Shared delivery This strategy is used in many languages: Java, ECMAScript, Python, Ruby, Visual Basic, and so on. In addition, the Python community has used this term, and other languages can use the term, because other names tend to make people feel confused. In most cases, such as in Java,ecmascript or Visual Basic, this strategy is also known as passing by value-meaning: Special values-reference copies (replicas).

On the one hand, it's like this--the argument passed to the function inside is just a name for the bound value (the reference address) and does not affect the external object.

On the other hand, if you don't delve into it, these terms are really considered to be eating wrong, because many forums are saying how to pass objects to JavaScript functions.

The general theory does have a value-transfer argument: But at this point the value is what we call an address copy (a copy), so it doesn't break the rules.

In Ruby, this strategy is called passing by reference. Again: It is not passed as a copy of a large structure (for example, not by value), and on the other hand, we do not have a reference to the original object and cannot modify it; Therefore, the concept of a cross term may be more confusing.

There is no special case for interviewing by reference, as in the case of a particular case passed by value.

But it is still necessary to understand these strategies in the above mentioned technologies (Java, ECMAScript, Python, Ruby, other), in fact--they use the strategy is to share delivery.

By sharing and pointers

For с/с+ +, this strategy is the same in mind and by pointer value, but there is one important difference-the policy can dereference pointers and completely alter objects. In general, however, assigning a value (address) pointer to a new memory block (that is, a previously referenced block of memory remains unchanged), and changing object properties by using a pointer can affect Adong external objects.

So, and the pointer category, we can obviously see that this is delivered by address value. In this case, passing by sharing is just "syntactic sugar," like pointer assignment behavior (but not dereference), or modifying a property (without dereference) as a reference, and sometimes it can be named "Security pointer."

However, с/с+ + has special syntactic sugars when referencing object properties without a clear pointer to the dereference:

Copy Code code as follows:

Obj->x instead of (*obj). x

This ideology, which is most closely related to C + +, can be seen in the implementation of the smart pointer, for example, in boost:: shared_ptr, overloading the assignment operator and copy constructor, and using the object's reference counter to delete the object through the GC. This type of data even has a similar name-shared _ptr.

ECMAScript implementation

Now we know the policy that ECMAScript objects as arguments--by sharing: Modifying the properties of a parameter will affect the external, and the assignment will not affect the external object. But, as we mentioned above, the ECMAScript developers generally call it: passing by value, except that the value is a copy of the reference address.

JavaScript inventor Brendan Aichy also wrote: A copy of a reference is passed (a copy of the address). So the forum has been said by the value of transmission, in this interpretation, is also true.

Rather, this behavior can be understood as a simple assignment, and we can see that the interior is a completely different object, except that it refers to the same value-that is, the address copy.

ECMAScript Code:

Copy Code code as follows:

var foo = {x:10, y:20};
var bar = foo;

Alert (bar = = foo); True

bar.x = 100;
BAR.Y = 200;

alert ([Foo.x, Foo.y]); [100, 200]

That is, two identifiers (name bindings) are bound to the same object in memory, sharing this object:

Foo value:addr (0xFF) => {x:100, y:200} (address 0xFF) <= bar value:addr (0xFF)
For the assignment, the binding is the new object identifier (the new address) and does not affect the previously bound object:

Copy Code code as follows:

Bar = {z:1, q:2};

alert ([Foo.x, Foo.y]); [100, 200]– hasn't changed.
alert ([Bar.z, bar.q]); [1, 2]– but is now referring to the new object

That is, Foo and bar now have different values and different addresses:

Copy Code code as follows:

Foo value:addr (0xFF) => {x:100, y:200} (address 0xFF)
Bar value:addr (0xFA) => {z:1, q:2} (address 0xFA)

Again, the value of the object here is the address, not the object structure itself, assigning the variable to another variable--a reference to the assignment value. So two variables refer to the same memory address. The next assignment, which is the new address, resolves the address binding to the old object and then binds it to the address of the new object, which is the most important difference to be passed by reference.

Furthermore, if only the abstraction level provided by the ECMA-262 standard is considered, we see only the concept of "value" in the algorithm, the implementation of the "value" (Can be the original value, can also be the object), but according to our definition above, it can be called "by value", because the reference address is also a value.

However, in order to avoid misunderstanding (why the properties of an external object can be changed within a function), there is still a need to consider the details of the implementation dimension--we see it as shared, or in other words--by a safe pointer, and the security pointer is not able to dereference and alter the object, but you can modify the object's property values.

Term version

Let's define the term version of the policy in ECMAScript.

It can be called "pass by Value"--the value here is a special case where the value is the address copy. From this level we can say: ECMAScript in addition to the exception of objects are passed by value, this is actually ECMAScript abstract level.

Or for this case, specifically referred to as "by sharing," through which you can see the difference between traditional and by-reference, which can be divided into 2 cases: 1: The original value is passed by value; 2: objects are passed by share.

The phrase "object to function by reference type" has nothing to do with ECMAScript, and it is wrong.

Conclusion

I hope this article will help to understand more about the details and the implementation in ECMAScript. As always, if there are any questions, welcome to the discussion.