细品javascript 寻址,闭包,对象模型和相关问题

正是因为JS是动态语言，所以JS的寻址是现场寻址，而非像C一样，编译后确定。此外，JS引入了this指针，这是一个很麻烦的东西，因为它“隐式”作为一个参数传到函数里面。我们先看“作用域链”话题中的例子：
var testvar = 'window属性';
var o1 = {testvar:'1', fun:function(){alert('o1: '+this.testvar);}};
var o2 = {testvar:'2', fun:function(){alert('o2: '+this.testvar);}};
o1.fun(); // '1'
o2.fun(); // '2'
o1.fun.call(o2); //'2'三次alert结果并不相同，很有趣不是么？其实，所有的有趣、诡异的概念最后都可以归结到一个问题上，那就是寻址。
简单变量的寻址
JS是静态还是动态作用域？
告诉你一个很不幸的消息，JS是静态作用域的，或者说，变量寻址比perl之类的动态作用域语言要复杂得多。下面的代码是程序设计语言原理上面的例子：
01| function big(){
02| var x = 1;
03| eval('f1 = function(){echo(x)}');
04| function f2(){var x = 2;f1()};
05| f2();
06| };
07| big();
输出的是1，和pascal、ada如出一辙，虽然f1是用eval动态定义的。另外一个例子同样来自程序设计语言原理：
function big2(){
var x = 1;
function f2(){echo(x)}; //用x的值产生一个输出
function f3(){var x = 3;f4(f2)};
function f4(f){var x = 4;f()};
f3();
}
big2();//输出1：深绑定；输出4：浅绑定；输出3：特别绑定
输出的还是1，说明JS不仅是静态作用域，还是深绑定，这下事情出大了……
ARI的概念
为了解释函数（尤其是允许函数嵌套的语言中，比如Ada）运行时复杂的寻址问题，《程序设计语言原理》一书中定义了“ARI”：它是堆栈上一些记录，包括：
函数地址
局部变量
返回地址
动态链接
静态链接
这里，动态链接永远指向某个函数的调用者（如b执行时调用a，则a的ARI中，动态链接指向b）；静态链接则描述了a定义时的父元素，因为函数的组织是有根树，所以所有的静态链接汇总后一定会指向宿主（如window），我们可以看例子（注释后为输出）：
var x = 'x in host';
function a(){echo(x)};
function b(){var x = 'x inside b';echo(x)};
function c(){var x = 'x inside c';a()};
function d(){
var x = 'x inside d,a closure-made function';
return function(){echo(x)}};
a();// x in host
b();// x inside b
c();// x in host
d()();// x inside d,a closure-made function在第一句调用时，我们可以视作“堆栈”上有下面的内容（左边为栈顶）：
[a的ARI] → [宿主]A的静态链直直的戳向宿主，因为a中没有定义x，解释器寻找x的时候，就沿着静态链在宿主中找到了x；对b的调用，因为b的局部变量里记录了x，所以最后echo的是b里面的x：'x inside b'；
现在，c的状况有趣多了，调用c时，可以这样写出堆栈信息：
动态链：[a]→[c]→[宿主]
静态链：[c]→[宿主]；[a]→[宿主]
因为对x的寻址在调用a后才进行，所以，静态链接还是直直的戳向宿主，自然x还是'x in host'咯！
d的状况就更加有趣了，d创建了一个函数作为返回值，而它紧接着就被调用了~因为d的返回值是在d的生命周期内创建的，所以d返回值的静态链接戳向d，所以调用的时候，输出d中的x：'x inside d,a closure-made function'。
静态链接的创建时机
月影和amingoo说过，“闭包”是函数的“调用时引用”，《程序设计语言原理》上面干脆直接叫ARI，不过有些不同的是，《程序设计语言原理》里面的ARI保存在堆栈中，而且函数的生命周期一旦结束，ARI就跟着销毁；而JS的闭包却不是这样，闭包被销毁，当且仅当没有指向它和它的成员的引用（或者说，任何代码都无法找到它）。我们可以简单地认为函数ARI就是一个对象，只不过披上了函数的“衣服”而已。
《程序设计语言原理》描述的静态链是调用时创建的，不过，静态链的关系却是在代码编译的时候就确定了。比如，下面的代码：
PROCEDURE a;
PROCEDURE b;
END
PEOCEDURE c;
END
END
中，b和c的静态链戳向a。如果调用b，而b中某个变量又不在b的局部变量中时，编译器就生成一段代码，它希望沿着静态链向上搜堆栈，直到搜到变量或者RTE。
和ada之类的编译型语言不同的是，JS是全解释性语言，而且函数可以动态创建，这就出现了“静态链维护”的难题。好在，JS的函数不能直接修改，它就像erl里面的符号一样，更改等于重定义。所以，静态链也就只需要在每次定义的时候更新一下。无论定义的方式是function(){}还是eval赋值，函数创建后，静态链就固定了。
我们回到big的例子，当解释器运行到“function big(){......}”时，它在内存中创建了一个函数实例，并连接静态链接到宿主。但是，在最后一行调用的时候，解释器在内存中画出一块区域，作为ARI。我们不妨成为ARI[big]。执行指针移动到第2行。
执行到第3行时，解释器创建了“f1”实例，保存在ARI[big]中，连接静态链到ARI[big]。下一行。解释器创建“f2”实例，连接静态链。接着，到了第5行，调用f2，创建ARI[f1]；f2调用f1，创建ARI[f1]；f1要输出x，就需要对x寻址。
简单变量的寻址
我们继续，现在要对x寻址，但x并不出现在f1的局部变量中，于是，解释器必须要沿着堆栈向上搜索去找x，从输出看，解释器并不是沿着“堆栈”一层一层找，而是有跳跃的，因为此时“堆栈”为：
|f1 | ←线程指针
|f2 | x = 2
|big | x = 1
|HOST|
如果解释器真的沿着堆栈一层一层找的话，输出的就是2了。这就触及到Js变量寻址的本质：沿着静态链上搜。
继续上面的问题，执行指针沿着f1的静态链上搜，找到big，恰好big里面有x=1，于是输出1，万事大吉。
那么，静态链是否会接成环，造成寻址“死循环”呢？大可不用担心，因为还记得函数是相互嵌套的么？换言之，函数组成的是有根树，所有的静态链指针最后一定能汇总到宿主，因此，担心“指针成环”是很荒谬的。（反而动态作用域语言寻址容易造成死循环。）
现在，我们可以总结一下简单变量寻址的方法：解释器现在当前函数的局部变量中寻找变量名，如果没有找到，就沿着静态链上溯，直到找到或者上溯到宿主仍然没有找到变量为止。
ARI的生命
现在来正视一下ARI，ARI记录了函数执行时的局部变量（包括参数）、this指针、动态链和最重要的——函数实例的地址。我们可以假想一下，ARI有下面的结构：
ARI :: {
variables :: *variableTable, //变量表
dynamicLink :: *ARI, //动态链接
instance :: *funtioninst //函数实例
}
variables包括所有局部变量、参数和this指针；dynamicLink指向ARI被它的调用者；instance指向函数实例。在函数实例中，有：
functioninst :: {
source :: *jsOperations, //函数指令
staticLink :: *ARI, //静态链接
......
}
当函数被调用时，实际上执行了如下的“形式代码”：
*ARI p;
p = new ARI();
p->dynamicLink = thread.currentARI;
p->instance = 被调用的函数
p->variables.insert(参数表，this引用)
thread.transfer(p->instance->operations[0])
看见了么？创建ARI，向变量表压入参数和this，之后转移线程指针到函数实例的第一个指令。
函数创建的时候呢？在函数指令赋值之后，还要：
newFunction->staticLink = thread.currentARI;
现在问题清楚了，我们在函数定义时创建了静态链接，它直接戳向线程的当前ARI。这样就可以解释几乎所有的简单变量寻址问题了。比如，下面的代码：
function test(){
for(i=0;i<5;i++){
(function(t){ //这个匿名函数姑且叫做f
setTimeout(function(){echo(''+t)},1000) //这里的匿名函数叫做g
})(i)
}
}
test()
这段代码的效果是延迟1秒后按照0 1 2 3 4的顺序输出。我们着重看setTimeout作用的那个函数，在它创建时，静态链接指向匿名函数f，f的（某个ARI的）变量表中含有i（参数视作局部变量），所以，setTimeout到时时，匿名函数g搜索变量t，它在匿名函数f的ARI里面找到了。于是，按照创建时的顺序逐个输出0 1 2 3 4。
公用匿名函数f的函数实例的ARI一共有5个（还记得函数每调用一次，ARI创建一次么？），相应的，g也“创建”了5次。在第一个setTimeout到时之前，堆栈中相当于有下面的记录（我把g分开写成5个）：
+test的ARI [循环结束时i=5]
| f的ARI；t=0 ←——————g0的静态链接
| f的aRI ；t=1 ←——————g1的静态链接
| f的aRI ；t=2 ←——————g2的静态链接
| f的aRI ；t=3 ←——————g3的静态链接
| f的aRI ；t=4 ←——————g4的静态链接
\------
而，g0调用的时候，“堆栈”是下面的样子：
+test的ARI [循环结束时i=5]
| f的ARI ；t=0 ←——————g0的静态链接
| f的ARI ；t=1 ←——————g1的静态链接
| f的ARI ；t=2 ←——————g2的静态链接
| f的ARI ；t=3 ←——————g3的静态链接
| f的ARI ；t=4 ←——————g4的静态链接
\------
+g0的ARI
| 这里要对t寻址，于是……t=0
\------
g0的ARI可能并不在f系列的ARI中，可以视作直接放在宿主里面；但寻址所关心的静态链接却仍然戳向各个f的ARI，自然不会出错咯~因为setTimeout是顺序压入等待队列的，所以最后按照0 1 2 3 4的顺序依次输出。
函数重定义时会修改静态链接吗？
现在看下一个问题：函数定义的时候会建立静态链接，那么，函数重定义的时候会建立另一个静态链接么？先看例子：
var x = "x in host";
f = function(){echo(x)};
f();
function big(){
var x = 'x in big';
f();
f = function(){echo (x)};
f()
}
big()
输出：
x in host
x in host
x in big
这个例子也许还比较好理解，big运行的时候重定义了宿主中的f，“新”f的静态链接指向big，所以最后一行输出'x in big'。
但是，下面的例子就有趣多了：
var x = "x in host";
f = function(){echo(x)};
f();
function big(){
var x = 'x in big';
f();
var f1 = f;
f1();
f = f;
f()
}
big()
输出：
x in host
x in host
x in host
x in host
不是说重定义就会修改静态链接么？但是，这里两个赋值只是赋值，只修改了f1和f的指针（还记得JS的函数是引用类型了么？），f真正的实例中，静态链接没有改变！。所以，四个输出实际上都是宿主中的x。
结构（对象）中的成分（属性）寻址问题
请基督教(java)派和摩门教(csh)派的人原谅我用这个奇怪的称呼，不过JS的对象太像Hash表了，我们考虑这个寻址问题：
a.b编译型语言会生成找到a后向后偏移一段距离找b的代码，但，JS是全动态语言，对象的成员可以随意增减，还有原型的问题，让JS对象成员的寻址显得十分有趣。
对象就是哈希表
除开几个特殊的方法（和原型成员）之外，对象简直和哈希表没有区别，因为方法和属性都可以存储在“哈希表”的“格子”里面。月版在他的《JS王者归来》里面就实现了一个HashTable类。
对象本身的属性寻址
“本身的”属性说的是hasOwnProperty为真的那些属性。从实现的角度看，就是对象自己的“哈希表”里面拥有的成员。比如：
function Point(x,y){
this.x = x;
this.y = y;
}
var a = new Point(1,2);
echo("a.x:"+a.x)
Point构造器创建了“Point”对象a，并且设置了x和y属性；于是，a的成员表里面，就有：
| x | ---> 1
| y | ---> 2
搜索a.x时，解释器先找到a，然后在a的成员表里面搜索x，得到1。
从构造器给对象设置方法不是好策略，因为它会造成两个同类的对象方法不等：
function Point(x,y){
this.x = x;
this.y = y;
this.abs = function(){return Math.sqrt(this.x*this.x+this.y*this.y)}
}
var a = new Point(1,2);
var b = new Point(1,2);
echo("a.abs == b.abs ? "+(a.abs==b.abs));
echo("a.abs === b.abs ? "+(a.abs===b.abs));
两个输出都是false，因为第四行中，对象的abs成员（方法）每次都创建了一个，于是，a.abs和b.abs实际上指向两个完全不同的函数实例。因此，两个看来相等的方法实际上不等。
扯上原型的寻址问题
原型是函数（类）的属性，它指向某个对象（不是类）。“原型”思想可以类比“照猫画虎”：类“虎”和类“猫”没有那个继承那个的关系，只有“虎”像“猫”的关系。原型着眼于相似性，在js中，代码估计可以写作：
Tiger.prototype = new Cat()函数的原型也可以只是空白对象：
SomeClass.prototype = {}我们回到寻址上来，假设用.来获取某个属性，它偏偏是原型里面的属性怎么办？现象是：它的确取到了，但是，这是怎么取到的？如果对象本身的属性和原型属性重名怎么办？还好，对象本身的属性优先。
把方法定义在原型里面是很好的设计策略。假如我们改一下上面的例子：
function Point(x,y){
this.x = x;
this.y = y;
}
Point.prototype.abs = function(){return Math.sqrt(this.x*this.x+this.y*this,y)}
var a = new Point(1,2);
var b = new Point(1,2);
echo("a.abs == b.abs ? "+(a.abs==b.abs));
echo("a.abs === b.abs ? "+(a.abs===b.abs));
这下，输出终于相等了，究其原因，因为a.abs和b.abs指向的是Point类原型的成员abs，所以输出相等。不过，我们不能直接访问Point.prototype.abs，测试的时候直接出错。更正：经过重新测试，“Point.prototype.abs不能访问”的问题是我采用的JSCOnsole的问题。回复是对的，感谢您的指正！
原型链可以很长很长，甚至可以绕成环。考虑下面的代码：
A = function(x){this.x = x};
B = function(x){this.y = x};
A.prototype = new B(1);
B.prototype = new A(1);
var a = new A(2);
echo(a.x+' , '+a.y);
var b = new B(2);
echo(b.x+' , '+b.y);
这描述的关系大概就是“我就像你，你也像我”。原型指针对指造成了下面的输出：
2 , 1
1 , 2
搜索a.y的时候，沿着原型链找到了“a.prototype”，输出1；b.x也是一样的原理。现在，我们要输出“a.z”这个没有注册的属性：
echo(tyoeof a.z)我们很诧异，这里并没有死循环，看来解释器有一个机制来处理原型链成环的问题。同时，原型要么结成树，要么就成单环，不会有多环结构，这是很简单的图论。
this:函数中的潜规则
方法（函数）调用中最令人烦恼的潜规则就是this问题。从道理上讲，this是一个指针，戳向调用者（某个对象）。但假如this永远指向调用者的话，世界就太美好了。但这个可恶的指针时不时的“踢你的狗”。可能修改的情况包括call、apply、异步调用和“window.eval”。
我更愿意把this当做一个参数，就像lua里面的self一样。lua的self可以显式传递，也可以用冒号来调用：
a:f(x,y,z) === a.f(a,x,y,z)JS中“素”的方法调用也是这个样子：
a.f(x,y,z) === a.f.call(a,x,y,z)f.call才是真正“干净”的调用形式，这就如同lua中干净的调用一般。很多人都说lua是js的清晰版，lua简化了js的很多东西，曝光了js许多的潜规则，着实不假。
修正“this”的原理
《王者归来》上面提到的“用闭包修正this”，先看代码：
button1.onclick = (
function(e){return function(){button_click.apply(e,arguments)}}
)(button1)别小看了这一行代码，其实它创建了一个ARI，将button1绑定于此，然后返回一个函数，函数强制以e为调用者（主语）调用button_click，所以，传到button_click里的this就是e，也就是button1咯！事件绑定结束后，环境大概是下面的样子：
button1.onclick = _F_; //给返回的匿名函数设置一个名字
_F_.staticLink = _ARI_; //创建之后就调用的匿名函数的ARI
_ARI_[e] = button1 //匿名ARI参数表里面的e，同时也是_F_寻找的那个e
于是，我们单击button，就会调用_F_，_F_发起了一个调用者是e的button_click函数，根据我们前面的分析，e等于button1，所以我们得到了一个保险的“指定调用者”方法。或许我们还可以继续发挥这个思路，做成通用接口：
bindFunction = function(f,e){ //我们是好人，不改原型，不改……
return function(){
f.apply(e,arguments)
}
}