When writing Ajax methods, we often write code like this:
Ajax code:
The first time I read this code, I felt something was a little off, but I couldn't put my finger on it. As I learned more about Ajax code, this feeling stayed with me all the time. Later, I figured out where it came from.
Look at the startRequest function. We see that xmlHttp.onreadystatechange points to a function that is triggered when xmlHttpRequest.readyState changes. Let's look at the startRequest function again and imagine the steps of sending the entire request. Now we click a button, which triggers a startRequest function. The function proceeds downward. The first step is createXmlHttpRequest(), which creates an xmlHttpRequest object. When it completes, the value of xmlHttpRequest.readyState is 0 (tracked via window.alert). The program continues downward to xmlHttp.onreadystatechange = handlestatechange. Because the state has not changed (xmlHttpRequest.readyState is 0), the function is not triggered. Next are Open() and Send(). So, throughout the entire function, handlestatechange should never have been triggered, but why is the result correct?
Later, I used window.alert to track the changes of xmlHttp.readystate and discovered that its actual running mechanism is like this. First, after creating an xmlHttpRequest object, the value of xmlHttp.readyState is 0, and then xmlHttp.onreadystatechange = handlestatechange is not executed. Next is open(); after this function runs, the value of xmlHttp.readyState becomes 1. Then there will be a breakpoint at the Open() function, preserving the current state, and then it returns to execute xmlHttp.onreadystatechange = handlestatechange, and then executes the Send() function. After this function runs, the value of xmlHttp.readyState becomes 2, and then it returns again to execute xmlHttp.onreadystatechange = handlestatechange. And so on.
The browser cannot truly program in an object-oriented way, so it found a compromise, but this approach looks neither one thing nor the other. After thinking for a long time and discussing with a classmate, I finally arrived at this conclusion.
onreadystatechange: set to a pointer to the handlestatechange function (a bit harder to understand)
A function is a subroutine that performs a specific function. After compilation, its executable code is allocated in the code segment, while its parameters and variables are in the stack segment. Therefore, when the main program calls a function, it actually transfers the program execution address to the entry address of the function in the code segment to execute. That is, each function has a definite entry address in the code segment. According to this, when the program encounters a return instruction (indicating the end of the program), it returns to the breakpoint of the function caller and continues execution. Since a function has a definite entry address (in fact, the function name represents its entry address), it can be pointed to by a pointer, which is also called a function pointer.
Original address: http://blog.chinaunix.net/uid-20730110-id-1883890.html