JavaScript の原理：クロージャの真実

ECMAScript 5.1 を前提に JavaScript のクロージャの原理をメモっとく。クロージャの真実はこれ。

レキシカル環境で検索しても説明がほとんど出てこない。誰かが説明してくれたらいいのになと思ってたので、厳密さには欠けるかもしれないが記事にしてみることにした。ECMAScript の仕様によって実現されているクロージャを理解する価値はきっとある。

# クロージャでカウンターの例

下記のコードはクロージャでカウンターを作る例。加算されていく `var n` ってどこに存在し続けるのか？この記事ではそういう疑問を解決しよう。

```js:example.js
function createCounter() {
  var n = 0;
  return function() {
    return n++;
  }
}

var count = createCounter();
print(count()); // 0
print(count()); // 1
print(count()); // 2
```

コードは SpiderMonkey で検証してるので標準出力関数が `print` だけど、`console.log` に置き換えればブラウザでも動作するはず。なお、OS X で Homebrew が入ってるなら下記のコマンドで SpiderMonkey をインストールして、コードを実行できる。

```bash
$ brew install spidermonkey
$ js example.js
```

# レキシカルスコープとダイナミックスコープ

クロージャの話をすると絶対出てくるレキシカルスコープ（静的スコープ）とダイナミックスコープ（動的スコープ）。クロージャの原理はレキシカルスコープが支えていて、ダイナミックスコープにクロージャはないんだよね。

下記のコードを実行すると `10` が出力される。JavaScript はレキシカルスコープだからね。でも、ダイナミックスコープだったら `20` が出力される。

```js:scope.js
var x = 10;

function foo() {
  print(x); // 10
}

function bar() {
  var x = 20;
  foo();
}

bar();
```

Perl はレキシカルスコープとダイナミックスコープを使い分けられるので、前述のコードをダイナミックスコープで書いてみる。

```pl:scope.pl
$x = 10;

sub foo {
  print $x, "\n"; # 20
}

sub bar {
  local $x = 20;
  foo();
}

bar();
```

OS X なら下記のコマンドでコードを実行できる。ターミナルに `20` が出力されたはず。

```bash
$ perl scope.pl
```

レキシカルスコープとダイナミックスコープの違いは、コード上で決まるか実行上で決まるかという違い。コード上では関数 `foo` の定義元にあるのは `10` に初期化された `var x` になる。実行上では `foo` の呼出元にあるのは `20` に初期化された `var x` になる。上記のコードの場合、変数 `x` をコード上と実行上のどっちの方法で解決しているかで出力が違うことになる。

# ECMAScript 5.1 のレキシカルスコープの原理

JavaScript はレキシカルスコープだ。それを JavaScript の仕様 ECMAScript 5.1 ではどうやって実現しているのかを見ていこう。

## レキシカル環境

レキシカル環境はコード上の入れ子構造と識別子から変数と関数への関連を保持している。

レキシカル環境は例を見た方が理解しやすい。scope.js のレキシカル環境は下記のオブジェクト図になる。

```js:scope.js
var x = 10;

function foo() {
  print(x); // 10
}

function bar() {
  var x = 20;
  foo();
}

bar();
```

![scope.js のレキシカル環境のオブジェクト図](http://www.plantuml.com/plantuml/img/RO_13i8W343lV4L_W6HwD7CtVy34a_F0a9afQmq3CsFsxx8WOoHUAEsZhsLuTFWKHlGmsBTM_ZITjAxNZ55pLzB2JLCZD0i1TZ327ZP5obiYNpct3gNj22-9DCBa95SUyCMMctzkb2HpzHrbg5OP9MVLh4EdzGhm8uyRHhjVQ5Q7iFP-fbICkd9HLH7o4rzj6At-CtCQGcQj4M3SmRQeSKhytu0Vp0Py0G00)

レキシカル環境は下記のプロパティを持つオブジェクトと考える。

* record: 環境レコード
* outer: 外側のレキシカル環境への参照

globalEnv はグローバルなレキシカル環境だ。fooEnv は関数 `foo` のレキシカル環境で、その外側のレキシカル環境は globalEnv だ。なお、global はいわゆるグローバルオブジェクトだ。例えば、ブラウザー上で実行する JavaScript ならグローバルオブジェクトは `window` になる。

環境レコードはレキシカル環境の識別子と値を記録する。ただし、グローバル環境の環境レコードはグローバルオブジェクトへの参照になる。`var x = 10;` がグローバルオブジェクトのプロパティに追加されるのはこのためだ。`var x = 20;` は barEnv の環境レコードに追加される。（仕様の環境レコードはもう少し複雑なので、この説明は正確ではない。）

## 実行コンテキスト

実行コンテキストはある時点の実行上の入れ子構造をスタックとして保持している。

実行コンテキストも例を見た方が理解しやすい。scope.js の `print(x);` 時点での実行コンテキストは下記のオブジェクト図になる。（PlantUML を使いこなせてなくてスタック感は全然表せてないけど……。）

![scope.js の print(x); 時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/VL913i8W4BppYlr0JVLej1VZ1xnQ3nIfgI8OfAR6zEzkG-c2KIzbcPaTXgNtIwDltF8htDrJIVpQHhZsgXWprLaA1oTbAgwsdHGRrx5a1qkG-W5hM8smVXHJNsrCQAAIEWOibbVS1ZcL91-mM3uToAOAnLOAOuyKg4XOqpffaTIjKabCTF5BRF7g2GoTt-xfap6_90Qb1kYMiCXBtHF_pyj3OsZKTgYRvxJ7G8ZiwrOBrnXz80RjK-RZfMQp7nD68def6bUMXT4as7ZR2DjbQUnWJ4GOJqICDj6FCQ3-m3S0)

実行コンテキストは下記のプロパティを持つオブジェクトと考える。

* env: レキシカル環境

globalExecCtx はグローバルな実行コンテキストで最初に生成されてスタックに積まれる。globalExecCtx の実行コンテキストで関数 `bar` が呼び出されたときに barExecCtx は生成されてスタックに積まれる。barExecCtx の実行コンテキストで関数 `foo` が呼び出されたときに fooExecCtx は生成されてスタックに積まれる。

`print(x);` を実行するタイミングだと図のように globalExecCtx・barExecCtx・fooExecCtx の3つの実行コンテキストが存在する。関数 `foo` の実行が終了すると fooExecCtx の実行コンテキストも終了する。

## 識別子の解決

さあ `print(x);` の変数 `x` を解決しよう。

識別子の解決も図から見てみる。実行コンテキストの図の変数 `x` の解決に利用される参照を矢印にしてみた。

![scope.js の print(x); 時点での実行コンテキストのオブジェクト図の変数 `x` の解決に利用される参照を矢印にしたもの](http://www.plantuml.com/plantuml/img/VLB13e8m3BtlA_e36FH8b8ln1xoA1vZ3e7CpOnYCyTyjZj7Dg1VMlVVwshMqvqPTIrDUeBLtAV1h6cwxYsHCLoV1BHobhagvwGLVsvv5DyX0g1kiO3d2wfPFURNMFeb2oXYmK5wLniif9Fc0XVAf89iY51l1jJbGGtd4wiuAWwJgf8pQH1TtX1QF9u4-yzixNMVC7P51eG3w31PfePx4__DoqDWqQdlKpLEwOqE8xEfESTjejIS6xMFcOrEpsOy98n5iYiQrJ18_6m8H6vyRODiaZnltriW4Umfg3iJe4_mQRoDNyWK0)

識別子の解決手順は単純だ。（仕様の識別子の解決はもう少し複雑なので、この説明は正確ではない。）

1. 現在の実行コンテキストのレキシカル環境を現在のレキシカル環境にする
2. 現在のレキシカル環境の環境レコードに対象の識別子が存在するか？
    - 存在する：その識別子の値を返す
    - 存在しない：現在のレキシカル環境の外側のレキシカル環境を現在のレキシカル環境にして2を再実行する

`print(x);` の場合は下記のようになる。

1. 現在の実行コンテキスト fooExecCtx のレキシカル環境 fooEnv を現在のレキシカル環境にする
2. 現在のレキシカル環境 fooEnv の環境レコードに対象の識別子 `x` が存在しないので、現在のレキシカル環境 fooEnv の外側のレキシカル環境 globalEnv を現在のレキシカル環境にする
3. 現在のレキシカル環境 globalEnv の環境レコード（グローバルオブジェクト）に対象の識別子 `x` が存在するので、`x` の値である `10` を返す。

# ECMAScript 5.1 のクロージャの原理

JavaScript のクロージャの原理を説明しよう。

## JavaScript のすべての関数はクロージャ

JavaScript のすべての関数はクロージャだ。どんな関数定義によって生成される関数オブジェクトでも、関数が定義されたレキシカル環境への参照（スコープ）を持つからだ。前項の図に関数オブジェクトを反映させると下記のようになる。

![scope.js の print(x); 時点での実行コンテキストのオブジェクト図に関数オブジェクトを追加](http://www.plantuml.com/plantuml/img/VL91SiCW3Bpp2dt0dhH7J-9Bftr0pxdOX7RIOl1Wx76duxz73iA2DEa5mUvgaGJ3zzdqZMiw6FoFLhYwi_HZfuMmxPUI7ZwrRHlzEYlvucUHdQ02PIOum9vWCzLRteUrCOctdB5YgRnjN9JpbkKhbigt2yMsGx5JqheJ5rHdh1szSaYQKUkiJ7G98RNuNHYCcVVw39M943A3em6OAtZU7St2_7zU0QAYKJkZxcd7Poo8PlSs6bapWUuqfK2axQs8e8ZIGTfUFUxbggPuNmtYvXUKvOFNGoBv1VmKHH77dc4qoGHxB_AHH6CcukWJWcoIJxUYsOLKmRLNHcBtSLR5pIL_mGi0)

これですべての準備ができた。クロージャでカウンターの例の原理を明らかにしよう。

## クロージャでカウンターの例の原理

クロージャでカウンターの例のコードを再掲する。

```js:example.js
function createCounter() {
  var n = 0;
  return function() {
    return n++;
  }
}

var count = createCounter();
print(count()); // 0
print(count()); // 1
print(count()); // 2
```

`var count = createCounter();` 時点での実行コンテキストのオブジェクト図は下記のようになる。

![var count = createCounter(); 時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/PP1T3i8W48JVEGKNu0AczgNH0tW3kbrDbIuDVwctTnjhaV92OEQRXS6_HfgrqvFquMsGLpT2Y9CHmlPFX20VnlRQN1Q4BYoYECcJH4hoB9jDfjGUSvJ4lcFU8LWtv4XRk3O6T6nIDCS7R1n3u507x6oaBzmKmZKIj7_mgZ8KQS3xI3ZiOwkKg1JEUx0p7XlMe59LtrMhxyXjrKsLrNwVcWt6FW00)

関数 `createCounter` の終了直前の実行コンテキストのオブジェクト図は下記のようになる。関数 `createCounter` の実行コンテキストとレキシカル環境が生成されている。そして、注目してほしいのは 関数 `createCounter` 内の無名関数が関数オブジェクト anonymousFunc として生成されているところ。

![関数 `createCounter` の終了直前の実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/XL913i8W4BppYlr0ZMUZlHXzW6SlbAwcIXT3mMYCVtVLre9Wl3HbTcPsbgKxDdIILhRGkQj6_jf6ETzgOQe3AWTxRIgfLnTKItSHqGbcW7I61SnxcCwb67JAedIuD9uSsa6U0qUNk1gQVVp5vuzb5fMnzTY_ZAh6imiNoMlz8nNxVGEXxMrB03I3wPRkEUBG8JV-6-e3CJUI9yEkFQao83zH9dcgSTSGrldyJvL84DPtofpmHp19XgwjyTrB7Pr2PMONQQUY23QJN11NusRzV8odOuoRApP5V7kzLxAw-2sEiZHCGFdZCfba7-u3)

`print(count());` 時点での実行コンテキストのオブジェクト図は下記のようになる。関数オブジェクト anonymousFunc が変数 `count` で参照できるようになる。

![`print(count());` 時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/TLBD3i8W3Bxp57s19PuNtSNe0tZsWjWObHN3OD4OtzsYqwrZkn3u_je2pVLCD-rr3KruMEJLdqs8jLNA7Ive0foiEsYxkQDPXxiI9oW1gOKLB3kOschierRzTwptQ9m_zfPAi2u6z4nIj7q3ngCEk7QHc4nvOs0O-zmJ09MmsDDhIlYhCDznrn1hXJrv1B2DPAg1EA59fCdHetQn-GecfqYKoX1EQOoxuKnx8bY9qz0v7fe3yaf5CNYVx9gObSMwAHdFn-YvASydRbV8k-rgP0yhFrTlO-uD)

変数 `count` を関数として呼び出した後の `return n++;` 時点での実行コンテキストのオブジェクト図は下記のようになる。

anonymousEnv の outer が createCounterEnv になっているのは、anonymousFunc の scope を anonymousEnv を生成するときに outer に設定するから。**関数の実行コンテキストではレキシカル環境の「外側のレキシカル環境」に関数オブジェクトの「スコープ」を設定する**という仕組みになっている。これまでのオブジェクト図を見返してもそうなってるはずだ。

![`count` を関数として呼び出した後の `return n++;` 時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/ZLD1RiCW4BppYls0evwZnfUeVK3FkH2wgjBY9S8G9QhozwvJOXQmcbuisDcPqIphyUj0H-tr06EuMEIlFvWG1wkKst-Y2V1XtLxRbpEQRJYhuWPhG3h11fvJcKxzpDFaw3AuEDwfTI6pCo85PaqrdvZYqJZ_dZtx0dKne6UGeiq9Z4STSEiYCJZfrGKf-xqZ05h3quwkIurtXxyZiucy50RN6febQxjw5YagKuhEXleQoVIYUQeMS_vjM9pF1AccmYgZSKTy5Fp6BcwIkP2lTUewyVBD0p1QcgMKN6zZP6o9SvDxwyhP9e_7AoD5nOwcrSwwBRPQ_UFVc0Ia_Wy0)

変数 `n` を解決しよう。

![`count` を関数として呼び出した後の `return n++;` 時点での実行コンテキストのオブジェクト図の変数 `n` の解決に利用される参照を矢印にしたもの](http://www.plantuml.com/plantuml/img/ZLD1RiCW4BppYls0evwZr9UeVK3FkH2wgjBY9S8G9QhozwvJObYmcbuisDcPqIphyUj0H-tr06EuMEIlFvWG1wkKst-Y2V1XtLxRbpEQRJWhSOCr89tW6JQfJAT-vcboT1bS7E_Kkf3P6Ia5PaqrdvZYqJZ_dZrxWReOq3D8qUO4ngCEk7MH69pqwa8f-xqZ05h3quwkIurtXxyZiqbv4GRN6febQxjw5YagKqHdGtsDPFgYUQgAEVysBCvdWbHJOPNHk2C-2dvZYrl9NCZNEdLTyVBD0p0gpL9AhhSnChR4kSczTNAsoUFnocnArM99qsvduHPRhVxnSx10Bmn-0000)

最初の `print(count());` が終了した時点での実行コンテキストのオブジェクト図は下記のようになる。createCounterEnv の n が1になっているよね。

![最初の `print(count());` が終了した時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/TLBD3i8W3Bxp57s17RmkkelH1_3i1R4nAYk6mQ8nlhj5frl7TY7m_RK5ckkPRjhh6fhmiCYhFviGQwkKErpG13XPTz1sSqUp3dSbJb02KWihM7OmjTNOHwtwxrZlqJX_x2sLO5qCw9caQFi6Z4STSEqYCPdoni0mzhad02fXiQVNbF1NORxZhY7M2dlo260RoLG3SKAJI9EZH-rYynLCJf4ebI6SqXXtmvdsHB0Ifw5pF3G7v9MAOl0-sJKnAujrKpAUZz5pKvvFtAwGTzlLo1vMVgxUnjmR)

これがクロージャの原理だ。

## createCounter を2回実行する

クロージャでカウンターの例のコードで関数 `createCounter` を2回実行してみる。もちろん別のカウンターが生成される。

```js:example2.js
function createCounter() {
  var n = 0;
  return function() {
    return n++;
  }
}

var count = createCounter();
print(count()); // 0
print(count()); // 1
print(count()); // 2

var count2 = createCounter();
print(count2()); // 0
print(count2()); // 1
print(count2()); // 2
```

これはなぜなのかも念のため考えてみる。と言っても、実行コンテキストのオブジェクト図をみればすぐに解るはず。

`print(count2());` 時点での実行コンテキストのオブジェクト図は下記のようになる。

![`print(count2());` 時点での実行コンテキストのオブジェクト図](http://www.plantuml.com/plantuml/img/XLFBRiCW4Bpp5Vi3bghjBKfzYTeFw3aNGb2L5YyH1YjHrNyFg4xD0aul5ipCphxm-7MYitHoWD5VZOvVTr8-34O8U_ZKoiE7iGTfNYzQxVn5i1jiGDC4Bx2TOPhwCeucyNUAUgULTSSbf6Ui3LwxI58mIm7AQUdrpWQAPF8hWTpsUqy0j87dFVsqXFSChOfBELO6s4hrr4g5_-JwXURcevR5fnW6l0LIVIPEQ199idGTR1XR0gmKkD9huaI5H9zHsRDUwO0v2tRB8yl1h1WWTy175gcDkjgkovvSjVd8yeBhXPKIlCyp4lMu5exxhk2OlVFklUFxdmki7lf35ej_SN6Dv0q0)

これですべての謎は解けたかな。

# 補足事項

本記事では下記を条件にすることで ECMAScript 5.1 の仕様を省略しているところがある。

1. strict モードコードのみ対象とする
2. eval コードは対象外とする
3. try 文 catch 節は対象外とする
4. 1と3を前提に実行コンテキストの LexicalEnvironment と VariableEnvironment を同一とみなして env の名前で参照する

# 参考文献

ECMA-262 Edition 5.1を読む
http://www.ecma-international.org/ecma-262/5.1/
http://dmitrysoshnikov.com/ecmascript/es5-chapter-3-1-lexical-environments-common-theory/
http://dmitrysoshnikov.com/ecmascript/es5-chapter-3-2-lexical-environments-ecmascript-implementation/