Some notes on javascript the core

Some notes on reading an article:  javascript the core

Execution context(EC)
VO
Variable Object (VO): includes variables and function declarations.              function expression will not be included in the VO
Activation Object (AO): include VO + function arguments
In ES5, the VO and AO is combined into the lexical environments.
Scope Chain
before we go to the __parent__ (upper context), first __proto__ chain is considered
Closure : Scope chain = Activation object + [[Scope]]
This Value
The value of this is determinate only once when entering the context.

Hoist

What really happen for hoist is: when execution engine is preparing the ‘execution context’ for the current function call, it will make global-context + this + outer-ev + local-vars ready. So it will scan the function body first and try to find out the variable and function declarations and prepare memory placeholders for them. After that it would start executing(interpreting) the function line by line. As a result, it makes the illusion that all the variables are ‘Hoisted’ to the top.

Advertisements

object vs closure

Consider this JavaScript function:

1
2
3
4
5
function fn()
{
    var a = 10;
    var b = { name: 'foo', n: 10 };
}

This might produce the following:

I say “might” because specific behaviors depend heavily on implementation. This post takes a V8-centric approach with many diagram shapes linking to relevant source code. In V8, only small integers are stored as values. Also, from now on I’ll show strings directly in objects to reduce visual noise, but keep in mind they exist separately in the heap, as shown above.

Now let’s take a look at closures, which are simple but get weirdly hyped up and mythologized. Take a trivial JS function:

1
2
3
4
5
function add(a, b)
{
        var c = a + b;
        return c;
}

This function defines a lexical scope, a happy little kingdom where the names a, b, and chave precise meanings. They are the two parameters and one local variable declared by the function. The program might use those same names elsewhere, but within add that’s what they refer to. And while lexical scope is a fancy term, it aligns well with our intuitive understanding: after all, we can quite literally see the bloody thing, much as a lexer does, as a textual block in the program’s source.

Having seen stack frames in action, it’s easy to imagine an implementation for this name specificity. Within add, these names refer to stack locations private to each running instance of the function. That’s in fact how it often plays out in a VM.

So let’s nest two lexical scopes:

1
2
3
4
5
6
7
8
9
function makeGreeter()
{
    return function hi(name) {
        console.log('hi, ' + name);
    }
}

var hi = makeGreeter();
hi('dear reader'); // prints "hi, dear reader"

That’s more interesting. Function hi is built at runtime within makeGreeter. It has its own lexical scope, where name is an argument on the stack, but visually it sure looks like it can access its parent’s lexical scope as well, which it can. Let’s take advantage of that:

1
2
3
4
5
6
7
8
9
function makeGreeter(greeting)
{
    return function greet(name) {
        console.log(greeting + ', ' + name);
    }
}

var heya = makeGreeter('HEYA');
heya('dear reader'); // prints "HEYA, dear reader"

A little strange, but pretty cool. There’s something about it though that violates our intuition:greeting sure looks like a stack variable, the kind that should be dead after makeGreeter()returns. And yet, since greet() keeps working, something funny is going on. Enter the closure:

The VM allocated an object to store the parent variable used by the inner greet(). It’s as ifmakeGreeter’s lexical scope had been closed over at that moment, crystallized into a heap object for as long as needed (in this case, the lifetime of the returned function). Hence the nameclosure, which makes a lot of sense when you see it that way. If more parent variables had been used (or captured), the Context object would have more properties, one per captured variable. Naturally, the code emitted for greet() knows to read greeting from the Context object, rather than expect it on the stack.

Here’s a fuller example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
function makeGreeter(greetings)
{
    var count = 0;
    var greeter = {};

    for (var i = 0; i < greetings.length; i++) {
        var greeting = greetings[i];

        greeter[greeting] = function(name) {
            count++;
            console.log(greeting + ', ' + name);
        }
    }

    greeter.count = function() { return count; }

    return greeter;
}

var greeter = makeGreeter(["hi", "hello", "howdy"])
greeter.hi('poppet'); // prints "howdy, poppet"
greeter.hello('darling'); // prints "howdy, darling"
greeter.count(); // returns 2

Well… count() works, but our greeter is stuck in howdy. Can you tell why? What we’re doing with count is a clue: even though the lexical scope is closed over into a heap object, the valuestaken by the variables (or object properties) can still be changed. Here’s what we have:

There is one common context shared by all functions. That’s why count works. But the greeting is also being shared, and it was set to the last value iterated over, “howdy” in this case. That’s a pretty common error, and the easiest way to avoid it is to introduce a function call to take the closed-over variable as an argument. In CoffeeScript, the do command provides an easy way to do so. Here’s a simple solution for our greeter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function makeGreeter(greetings)
{
    var count = 0;
    var greeter = {};

    greetings.forEach(function(greeting) {
        greeter[greeting] = function(name) {
            count++;
            console.log(greeting + ', ' + name);
        }
    });

    greeter.count = function() { return count; }

    return greeter;
}

var greeter = makeGreeter(["hi", "hello", "howdy"])
greeter.hi('poppet'); // prints "hi, poppet"
greeter.hello('darling'); // prints "hello, darling"
greeter.count(); // returns 2

It now works, and the result becomes:

That’s a lot of arrows! But here’s the interesting feature: in our code, we closed over two nested lexical contexts, and sure enough we get two linked Context objects in the heap. You could nest and close over many lexical contexts, Russian-doll style, and you end up with essentially a linked list of all these Context objects.

Of course, just as you can implement TCP over carrier pigeons, there are many ways to implement these language features. For example, the ES6 spec defines lexical environments as consisting of an environment record (roughly, the local identifiers within a block) plus a link to an outer environment record, allowing the nesting we have seen. The logical rules are nailed by the spec (one hopes), but it’s up to the implementation to translate them into bits and bytes.

You can also inspect the assembly code produced by V8 for specific cases. Vyacheslav Egorovhas great posts and explains this process along with V8 closure internals in detail. I’ve only started studying V8, so pointers and corrections are welcome. If you know C#, inspecting the IL code emitted for closures is enlightening – you will see the analog of V8 Contexts explicitly defined and instantiated.

Closures are powerful beasts. They provide a succinct way to hide information from a caller while sharing it among a set of functions. I love that they truly hide your data: unlike object fields, callers cannot access or even see closed-over variables. Keeps the interface cleaner and safer.

FROM HERE

another good one

that=this in javascript

Watch Out: Callbacks And Closures Sometimes Do Not Play Nicely

Of course there are always gotchas with JavaScript. Lets define a callback function:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
var createCallBack = function() { //First function
    return new function() { //Second function
        this.message = "Hello World";

        return function() { //Third function
            alert(this.message);
        }
    }
}

window.onload = createCallBack(); //Invoke the function assigned to createCallBack

Lets examine the above code. There are three function operators:

  1. The first function operator creates a function object and is assigned tocreatCallBack.
  2. The second function operator uses the constructor invocation pattern to create a new object.
  3. The third function operator is the result of the return statement. It is a function object and because it is an instance of Object, it gets returned instead of a new object (even though though the function was invoked with new – read constructor invocation pattern for more info).

When invoking the createCallBack variable, what gets passed to the window.onloadevent handler is the result of what is returned by the seond function operator, which is the code in the third function operator. Did you get that? Read this paragraph again until you understand, and if not, stick this code into your browser and play with it.

The above code looks alright, except that undefined gets alerted to the screen (try it for yourself). It turns out that when an event handler invokes a callback function, the function invocation pattern is used. This results in the this parameter being bound to the global object (it is one of the pitfalls of the function invocation pattern) instead of to the object that was created with the constructor invocation pattern. To note that this problem only occurs when one uses the constructor invocation pattern with callbacks like I have illustrated above. To get around this, apply the standard fix for function invocation by declaring a that variable to point to this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
var createCallBack = function() { //First function
    return new function() { //Second function
        var that = this;
        this.message = "Hello World";

        return function() { //Third function
            alert(that.message);
        }
    }
}

window.onload = createCallBack(); //Invoke the function assigned to createCallBack

Since the function invoked by the event handler (the third function) is a closure, it has access to the that variable (which is private), and so it has access to the new object created by the constructor invocation pattern.

Read More

 

JavaScript 中的函数既可以被当作普通函数执行,也可以作为对象的方法执行,这是导致 this 含义如此丰富的主要原因。一个函数被执行时,会创建一个执行环境(ExecutionContext),函数的所有的行为均发生在此执行环境中,构建该执行环境时,JavaScript 首先会创建 arguments变量,其中包含调用函数时传入的参数。接下来创建作用域链。然后初始化变量,首先初始化函数的形参表,值为 arguments变量中对应的值,如果 arguments变量中没有对应值,则该形参初始化为 undefined。如果该函数中含有内部函数,则初始化这些内部函数。如果没有,继续初始化该函数内定义的局部变量,需要注意的是此时这些变量初始化为 undefined,其赋值操作在执行环境(ExecutionContext)创建成功后,函数执行时才会执行,这点对于我们理解 JavaScript 中的变量作用域非常重要,鉴于篇幅,我们先不在这里讨论这个话题。最后为 this变量赋值,如前所述,会根据函数调用方式的不同,赋给 this全局对象,当前对象等。至此函数的执行环境(ExecutionContext)创建成功,函数开始逐行执行,所需变量均从之前构建好的执行环境(ExecutionContext)中读取。

javascrip closure

First, a very very good article explaining CLOSURE

Second, I like this answer in Stackoverflow:

A function in JavaScript is not just a reference to a set of instructions (as in C language) but also includes a hidden data structure which is composed of references to all nonlocal variables it uses (captured variables). Such two-piece functions are called closures. Every function in JavaScript can be considered a closure.

Closures are functions with a state. It is somewhat similar to “this” in the sense that “this” also provides state for a function but function and “this” are separate objects (“this” is just a fancy parameter, and the only way to bind it permanently to a function is to create a closure). While “this” and function always live separately, a function cannot be separated from its closure and the language provides no means to access captured variables.

Because all these external variables referenced by a lexically nested function are actually local variables in the chain of its lexically enclosing functions (global variables can be assumed to be local variables of some root function), and every single execution of a function creates new instances of its local variables, it follows that every execution of a function returning (or otherwise transferring it out, such as registering it as a callback) a nested function creates a new closure (with its own potentially unique set of referenced nonlocal variables which represent its execution context).

Also, it must be understood that local variables in JavaScript are created not on the stack frame but in the heap and destroyed only when no one is referencing them. When a function returns, references to its local variables are decremented but can still be non-null if during the current execution they became part of a closure and are still referenced by its lexically nested functions (which can happen only if the references to these nested functions were returned or otherwise transferred to some external code).

 

Let’s take a look at this small sample of a function that creates and returns another function. The returned function accepts one string argument and returns another string repeating the argument a number of times.

  1. function makeRepeater(times){
  2.     return function(text){
  3.         var message = ;
  4.         for (var i=0; i < times; i++) {
  5.             message += text + ‘ ‘;
  6.         }
  7.         return message;
  8.     };
  9. }

Let’s now write some code that uses that function.

  1. var threeTimes = makeRepeater(3);
  2. var fourTimes = makeRepeater(4);
  3. alert( threeTimes(‘hi’) );
  4. // => ‘hi hi hi ‘
  5. alert( fourTimes(‘hi’) );
  6. // => ‘hi hi hi hi ‘

Nothing spectacular, right? But look closely. The function returned by makeRepeater contains a reference to times, which is a local variable ofmakeRepeater. When we call threeTimes or fourTimes the makeRepeater call has already returned and times should be out of scope. Or should it?

Extra life for your local scope

You may try to argue and say that the times inside threeTimes is not a reference to the times from makeRepeater, but just a copy of that value. Well, sadly I’ll have to prove you wrong. Let’s modify our code just a little.

  1. var times;
  2. function makeRepeater(){
  3.     return function(text){
  4.         var message = ;
  5.         for (var i=0; i < times; i++) {
  6.             message += text + ‘ ‘;
  7.         }
  8.         return message;
  9.     };
  10. }
  11. times = 3;
  12. var threeTimes = makeRepeater();
  13. times = 4;
  14. var fourTimes = makeRepeater();
  15. alert( threeTimes(‘hi’) );
  16. // => ‘hi hi hi hi ‘  —> What?!?!
  17. alert( fourTimes(‘hi’) );
  18. // => ‘hi hi hi hi ‘

If it’s not clear yet, let me write it down for you. The returned function really keeps a reference to any outside values it will need when invoked. In our original example, it kept a reference to the times local variable at the time it was produced. If we had created other local variables insidemakeRepeater they would also become available inside the returned function. In other words, all the scope created during the call tomakeRepeater will be preserved for the returned function. This happens when the returned (or inner) function has a reference to anything defined in the parent (or outer) function, i.e. the parent local scope. When this happens, we say that a closure has been created.

Closures can be tricky

It’s important to understand the mechanics of closures to avoid subtle bugs in our code. Look at this piece of code, adapted from a real bug I had to fix.

  1. <input type=“button” value=“Button 1” id=“btn1”>
  2. <input type=“button” value=“Button 2” id=“btn2”>
  3. <input type=“button” value=“Button 3” id=“btn3”>
  4. “text/javascript”>
  5.     function createEventHandlers(){
  6.         var btn;
  7.         for(var i=1; i
  8.             btn = document.getElementById(‘btn’ + i);
  9.             btn.onclick = function(){
  10.                 alert(‘Clicked button #’ + i);
  11.             }
  12.         }
  13.     }
  14.     createEventHandlers();

If you put this code in a page and click the three buttons you will see that all of them will show the message “Clicked button #4”. Armed with our understanding of closures we can immediately understand that this bug is being caused by that reference to i used inside the event handler. We can fix that.

  1. function createEventHandlers(){
  2.     var btn;
  3.     for(var i=1; i <= 3; i++){
  4.         btn = document.getElementById(‘btn’ + i);
  5.         btn.onclick = createOneHandler(i);
  6.     }
  7. }
  8. function createOneHandler(number){
  9.     return function() {
  10.         alert(‘Clicked button #’ + number);
  11.     }
  12. }

The above code works because we are not creating functions inside the for loop, hence not producing closures on the same local scope. There is a different set of closures being produced by createOneHandler, but those are not pointing to the same parent scope. Each of these three new closures contain a different scope, created by each call to createOneHandler

Closing thoughts

Closures, of course, are not an exclusive feature of JavaScript. It’s a very important trait of functional languages. Even in C#, when we use lambdas, closures are created — many times without us noticing.

The key to properly using closures in our code is to pay attention to locally scoped values from the outer function being used in the body of the inner function. Most of the times this will work as intended by the developer but, when it doesn’t, stop and check if more than one closure is sharing the same local scope or if these local values are changing between the inner function creation and its invocation.

FROM HERE

Documentation and examples in Mozilla

groovy closure

Informal Guide

When using the Java programming language most executable code is enclosed in either static class methods or instance methods. (Code can also be enclosed in constructors, initializers, and initialization expressions, but those aren’t important here.) A method encloses code within curly brackets and assigns that block of code a method name. All such methods must be defined inside of a class of some type. For example, if you were to write a method that returned the square of any integer it may look like this:

package example.math;

public class MyMath {
   public static int square(int numberToSquare){
        return numberToSquare * numberToSquare;
   }
}

Now in order to use the square() method you need to reference the class and the method by name as follows:

import example.math.MyMath;
...
int x, y;
x = 2;
y = MyMath.square(x); // y will equal 4.

You can do the same thing in Groovy, but in groovy you can alternatively define the code without having to declare a class and a method as follows:

{ numberToSquare -> numberToSquare * numberToSquare }

In Groovy, this anonymous code block is referred to as a closure definition (see the Formal Guide section below for a more elaborate definition of terms). A closure definition is one or more program statements enclosed in curly brackets. A key difference between a closure and method is that closures do not require a class or a method name.

As you can see, the executable code is the same except you didn’t need to declare a class or assign the code a method name. While illustrative, the previous example is not all that useful because there is no way to use that closure once its created. It has no identifier (method name) so how can you call it? To fix that you assign the closure to a variable when it’s created. You can than treat that variable as the identifier of the closure and make calls on it.

The following shows the square() method re-written as a closure:

def x = 2

// define closure and assign it to variable 'c'
def c = { numberToSquare -> numberToSquare * numberToSquare }

// using 'c' as the identifer for the closure, make a call on that closure
def y = c(x)       // shorthand form for applying closure, y will equal 4
def z = c.call(x)  // longhand form, z will equal 4

What is really nice about closures is that you can create a closure, assign it to a variable, and then pass it around your program like any other variable. At first this seems a bit, well useless, but as you learn more about Groovy you’ll discover that closures are used all over the place.

As an example, let’s extend the java.util.Vector class from Java by adding a single method that allows you to apply a closure to every element in the vector. My new class, GVector, looks as follows:

package example

public class GVector extends java.util.Vector {
  public void apply( c ){
     for (i in 0..<size()){
        this[i] = c(this[i])
     }
  }
}

The apply() method takes a closure as an input parameter. For each element in the GVector, the closure is called passing in the element. The resulting value is then used to replace the element. The idea is that you can modify the contents of the GVector in place using a closure which takes each element and converts into something else.

Now we can call our new apply() method with any closure we want. For example, we will create a new GVector, populate it with some elements, and pass in the closure we created earlier, the one that squares an integer value.

import example
def gVect = new GVector()
gVect.add(2)
gVect.add(3)
gVect.add(4)

def c = { numberToSquare -> numberToSquare * numberToSquare }

gVect.apply(c) // the elements in the GVector have all been squared.

Because the apply() method on the GVector can be used with any closure, you can use any closure. For example, the following uses a closure that simply prints out the item its passed.

import example
def gVect = new GVector()
gVect.add(2)
gVect.add(3)
gVect.add(4)

def c2 = { value -> println(value) }

gVect.apply(c2) // the elements in the GVector have all been printed.

If you were to run the above script, assuming GVector from earlier is on your classpath, the output would look like this:

C:/> groovy myscript.groovy
4
9
16
C:/>

In addition to assigning closures to variables, you can also declare them directly as arguments to methods. For example, the above code could be re-written in the following manner:

import example
def gVect = new GVector()
gVect.add(2)
gVect.add(3)
gVect.add(4)

gVect.apply{ value -> println(value) }  // elements in GVector have been printed.

This example accomplishes the same thing as the first, but the closure is defined directly as an argument to the apply method of GVector.

The other important difference of a closure to a normal method is that a closure can refer to variables from the scope in which it is called (in fact this is where this language construct gets its name). Here is an example:

class Employee {
    def salary
}
def highPaid(emps) {
	def threshold = 150
	return emps.findAll{ e -> e.salary > threshold }
}

def emps = [180, 140, 160].collect{ val -> new Employee(salary:val) }

println emps.size()           // prints 3
println highPaid(emps).size() // prints 2

In this example, the closure block { e -> e.salary > threshold } refers to the threshold variable defined in thehighPaid() method. The example also used a closure to create the emps list.

Other Examples

  • You could define a closure that take a closure as argument, and combine the use of other Groovy techniques to do a lot of things. See the Closure, Category and JPA example

Closures vs. Code Blocks

A closure looks a lot like a regular Java or Groovy code block, but actually it’s not the same. The code within a regular code block (whether its a method block, static block, synchronized block, or just a block of code) is executed by the virtual machine as soon as it’s encountered. With closures the statements within the curly brackets are not executed until the call() is made on the closure. In the previous example the closure is declared in line, but it’s not executed at that time. It will only execute if the call() is explicitly made on the closure. This is an important differentiator between closures and code blocks. They may look the same, but they are not. Regular Java and Groovy blocks are executed the moment they are encountered; closures are only executed if the call() is invoked on the closure.