(新增官方回复)对【无类语言的OOP（JavaScript描述） 】一贴中第一个代码段的不同意见

几天前一个同事把这篇文章发给我看，当时我看到第一个代码的时候就有不同意见，实在不吐不快，不过由于论坛要注册三天后才能发帖，所以只有等到今天才能发贴。

原文地址：http://www.iteye.com/topic/89554

这个问题，在很多js书籍上也讲了，如果在构造函数里面写的话是会浪费内存的，所以我觉得还是尽量避免的好，用prototype得了……

LS，不说你了。你可能真的需要充电充电了。
首先，根据我列出的 ECMAScript 规范，识别“相等”函数需要进行函数代码的字符串比较。为了测试函数是被创建了还是只有一个引用，二者必须尽量排除函数体比较这个时间变量，采用空函数体（使用有函数体的代码时，时间会有微小的差别，但已经能做到不影响你的“客户端”应用了）。
那么，来测测这两段代码的效率：

// 这个能计算出引用赋值500000次所消耗的时间，5秒钟
fun = function () {}
a = []
time = {}
time.org = new Date().toTimeString()
for (var i = 0; i < 500000; i++) {
	a[i] = fun
}
time.after = new Date().toTimeString()
alert(time.org+'\n'+time.after)

// 假如按你所说，没有函数相等性识别机制，这段代码就完了；然而，它也耗时5秒钟
a = []
time = {}
time.org = new Date().toTimeString()
for (var i = 0; i < 500000; i++) {
	a[i] = function () {
		this.on = false
	}
}
time.after = new Date().toTimeString()
alert(time.org+'\n'+time.after)

你既然这么能质疑，还可以profile对象创建时，我给出的“逐个绑定”的代码效率如何，别忘了给字符串比较算法作算法时间复杂度分析；还有，让prototype的版本的构造函数中有一次引用赋值，否则就成了只创建对象而没有构造函数执行的版本了。

现在来解释你所说的函数比较返回 false 什么的问题。这根本就不是问题。对于任意两个函数，规范指出，函数比较必须返回 false；在进行引用赋值时，首先把函数封装为对象，引用比较执行函数对象的比较，返回 true。我所说的函数的相等性测试，指的是 JavaScript 实现中的一种机制（所有 ECMAScript 规范中表明“build-in”的章节都属此类），与语言的外在表现无关；在这里就是相等性测试与 === 测试无关，因为二者根本就不是同一概念。一个语言实现的优化，目的就是要在你从外部看不出来的情况下提高性能；现在看到的宏观表现，必然是语言语义层所反映的内容而非未优化的后果。

意思是：

按照规范，=== 两个函数比较返回false，同引用返回true。
后者prototye里函数的定义好理解，
前者function内定义函数，肯定是两个函数了，按照规范必须返回false。但是实际实现的时候，他们是在内存中是同一个函数。

是这么了解吧？

那我们按3楼的说法来做个测试：

我的提醒白提醒了。

因为你的第二个版本构造函数执行了100000次，LS！而你的第一个

function Darkness() {
}   

构造函数为空，在被 new 的时候无须执行！只要构造函数中有需要执行且不会被优化掉的语句，时间就会大幅增长。
我测试你的代码，前者3s，后者9s；前者构造函数中有简单引用赋值语句时5s。然后我注意到你的代码中有许多多余的空格，这会大大增加字符串比较的负担（因为它的算法时间复杂度是绝对的theta(n)）。去掉之后变成：

this.turnOn=function(){alert("bingo")}

时间竟然下降到5s。我觉得这不符合逻辑。排除可能存在的缓存问题后再测，6s。看来，后者花在检测上的时间才是主要矛盾。
你的这个代码最多能证明，在“超大规模”创建对象时最好还是让构造函数少做点事，快一点；但是，函数在内存中确实是只有一个。

PS: 至于你测的第二段代码要一分半钟，我估计是这个原因：首先，在浏览器中一次跑90秒是不可能的，它会跳出问是否继续执行的对话框，此时JS代码停止运行，但系统时间仍在继续。联想到你说第一个代码段耗时5秒，据此推测你的机器性能够戗。如果是浏览器IE，其内存管理问题很大，直接崩溃都有可能；如果是Firefox，在Geoko框架下创建对话框的耗时本来就大，再加上Java和JavaScript的垃圾收集器同时运行（关于Java垃圾收集器在极端情况下的性能问题参见《Effective Java》），会因为线程跳转过缓而加剧时间消耗。也就是说，因为一点机器性能不足而导致代码平白无故多跑很久。你觉得我的解释有道理吗？

我的机器确实是够呛，不过跑九十秒却是真的，而且是在没有跳出警告框的情况下，我现在正在看规范，在得出我的结论前，我先收回不是同一个内存的观点，不过我还是认为你原先的代码并不是最优化的。正如你说的“后者花在检测上的时间才是主要矛盾。”，你认为呢

PS."对于任意两个函数，规范指出，函数比较必须返回 false；"不知道你能否告诉我这个是在规范那里规定的？我找不到诶，而且假如真是如此，以下代码的比较同样应该返回false：

  function test() {alert("bingo");}
  
  function Light() {
    this.turnOn = test;
  }
  
  var a = new Light();
  var b = new Light();
  
  alert(a.turnOn === b.turnOn);
  alert(a.turnOn === test)

但很遗憾，这个比较返回的是true。

看来我就此开个 JavaScript 专栏一心和你们讨论这些问题算了。这帖子居然还有一群人跟在后面打“良好”“精华”，无语了…

火是要发的，问题也是要解决的。下面讲正经的。不仅仅讲给 keshin 一个人听，大家都来看下吧。我们开始从 === 运算符谈起。

请翻到 ECMA-262 e4 的 11.9.4 节，The Strict Equals Operator (===)。这里给出了 === 运算符的语法产生式和展开（注意，只是部分求值）步骤：

EqualityExpression === RelationalExpression is evaluated as follows:

1. Evaluate EqualityExpression.
2. Call GetValue(Result(1)).
3. Evaluate RelationalExpression.
4. Call GetValue(Result(3)).
5. Perform the comparison Result(4) === Result(2). (See below.)
6. Return Result(5).

它指出，对两个产生式的求值结果调用规范中的算法 GetValue(V)。那么翻到这一节，8.7.1 GetValue(V)。

1. If Type(V) is not Reference, return V.
2. Call GetBase(V).
3. If Result(2) is null, throw a ReferenceError exception.
4. Call the [[Get]] method of Result(2), passing GetPropertyName( V) for the property name.
5. Return Result(4).

根据第一句，判断 Type(V) 是不是引用。现在要分情况讨论一下。先解决你上一帖提出的问题。在你给出的构造函数中，需要执行的是这样一句：

	this.turnOn = test;

那么，检查 Type(this.turnOn)，是到一个 Object Type 的函数 test的引用。于是调用 GetBase(V) 获取到 trunOn 引用的基对象 this，此描述用函数的定义在 8.7 The Reference Type 中：

• GetBase(V). Returns the base object component of the reference V.

对象 this 不是 null，跳转第4步调用 8.6.2.1 节中 [[Get]](P) 算法，传递的属性名是 turnOn。根据算法

1. If O doesn't have a property with name P, go to step 4.
2. Get the value of the property.
3. Return Result(2).
4. ...

取到该属性的对应值，即内部记录的函数 test。现在我们知道了，是两个 test 在作比较。（友情提醒：请继续往下看。）那么返回 11.9.4 节。

现在只有 Step(5): Result(4) === Result(2). 是最重要的。旁边的(See below.)指出 === 的算法在下文，11.9.6 节 The Strict Equality Comparison Algorithm。在这一节我们看到了具体的算法。前面12步全是废话，看第13步：
[list=13]

Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.

[/list]
很明显，如果两个函数对象（只剩这一种可能了）可以被 joined，它们就相等。那么根据提示，翻到 13.1.2 Joined Objects。
下面是函数对象可被 joined 的条件：

• Any time a non-internal property of an object O is created or set, the corresponding property is immediately also created or set with the same value and attributes in all objects joined with O.
• Any time a non-internal property of an object O is deleted, the corresponding property is immediately also deleted in all objects joined with O.
• ...（这两句跟主题无关）

这两句话罗嗦死了，其实就四个字：“同生同死”——要求可被 joined 的对象们的属性要产生都产生，要删除都删除。现在以此条件看 test 函数，符合以上条件，可被 joined，于是 === 运算符返回 true。

解决下一个问题，你曾经写过的返回 false 的代码：

function Light() {
	this.turnOn = function () {
		alert("bingo");
	}
}

var lightA = new Light();
var lightB = new Light();

alert(lightA.turnOn === lightB.turnOn); 

前面步骤相同不用看了，只看最后一个步骤，

	function () {
		alert("bingo");
	}

函数们能否被 joined？当然不能，用肚脐眼都能看地很清楚，修改 lightA.turnOn 上的属性不会影响 lightB.turnOn。

问题解决完了，下面解释我提到过的函数相等性测试。第 13.1.1 节，Equated Grammar Productions 中的内容已经讲过，没看见拉倒。下面翻到课本：
这一节的算法中，用到函数相等性测试的只有 Step1

1. If there already exists an object E that was created by an earlier call to this section's algorithm, and if that call to this section's algorithm was given a FunctionBody that is equated to the FunctionBody given now, then go to step 13. (If there is more than one object E satisfying these criteria, choose one at the implementation's discretion.)

这一段话的意思很明显：如果函数相等性测试可用，就配合括号中的句子(If there is more than one object E satisfying these criteria, choose one at the implementation's discretion.)做优化；如果不可用，Step 1 忽略。

这里有一个隐含的内容：是否优化对语言语义无影响。这涉及编译原理的体系，即：优化措施属于实现层，实现层不可影响由语言规范所定义的语义层，即语言的外在表现。说白了，就是“规范是上帝，实现只能是上帝的羊羔，随你怎么折腾，不可僭越”，否则就是实现失败。所以我看到 keshin 这个第一帖中的代码时，想都不想就知道是语义的结果，跟实现无关。
以 Rhino 解释器（也就是 Firefox 的解释器啦）为例，一个函数对象（JavaScript 中函数没有对应原始类型，就是(is a) Object）在解释器中由两部分构成：一是可执行的继承 Scriptable，Callable 接口的 Java 类 BaseFunction 对象，外部 wrap 是 FunctionObject 类的对象。相等性测试通过的函数们，都是堆上的一个 BaseFunction，被存储为一个 FunctionNode，作为 JavaScript 函数执行时只调用一段代码块；但执行 === 比较时，只比较其在 JavaScript 中的外在表现，即 FunctionObject 是否相等，结果就是这样有些“奇怪”的表现。

讲解结束，下面是我对这个问题的个人意见。
我给出的代码，从效率角度来看，不是最优的；但从上文的叙述中可以看出，可以这样理解：

• 这可以作为一种不同于 prototype 的“新”的给对象绑定方法的形式，更加安全。对于这种观点和使用方式效率没有任何问题。
• 当作普通 prototype 的另一种写法来使用，相对于在代码中多消耗了一个 O(n) 级的算法，而且此算法来自 JavaScript 底层实现且可被加速，效率下降忽略不计，去掉 JS 代码中所有为空的行、无效空格，把所有换行换成 ; 损失就回来了；仅当处于“大规模的”循环中时才可视为一个 O(n) 算法，这种情况存在的可能性微乎其微，不过，还是那句话，尽量避免。

我的话说完了。请注意，下面不是答疑时间。

PS: 刚刚才看到 keshin 原帖新加的内容。ECMA 的人说的非常正确，不过他们不敢解释太多；态度很客气，这一点让我非常佩服。

临下班的时候看到Lich_Ray回帖，但是无奈mm在楼下等，只好把回帖拖到现在。

首先请Lich_Ray消消气，精华也好，良好也好，不过是抛给追求真相的过程而已。如果把这些浮云贴到自己身上，未免太过那个了一点。

好了，言归正传。

1、哥们的回帖中提到：“现在以此条件看 test 函数，符合以上条件，可被 joined，于是 === 运算符返回 true。”

之后又向我的肚脐眼挑战说：“函数们能否被 joined？当然不能，用肚脐眼都能看地很清楚，修改 lightA.turnOn 上的属性不会影响 lightB.turnOn。”

哥们，函数倒地能不能被join啊？

2、哥们说“下面解释我提到过的函数相等性测试。第 13.1.1 节，Equated Grammar Productions 中的内容已经讲过，没看见拉倒。”，不知道你这个是否是打算作为前面提到的“对于任意两个函数，规范指出，函数比较必须返回 false”的回答。

如果是，我不知道，你是否指的是下面红色的部分。

13.1.1 Equated Grammar Productions
Two uses of the FunctionBody grammar production are defined to be equated when one of the following
is true:
• Both uses obtained their FunctionBody from the same location in the source text of the same
ECMAScript program. This source text consists of global code and any contained function codes
according to the definitions in 10.1.2.
• Both uses obtained their FunctionBody from the same location in the source text of the same call to
eval (15.1.2.1). This source text consists of eval code and any contained function codes according
to the definitions in 10.1.2.
NOTE
Two uses of FunctionBody obtained from a call to the Function constructor 15.3.1 and 15.3.2) are
never equated. Also, two uses of FunctionBody obtained from two different calls to eval are never
equated, even if those two calls to eval were passed the same argument.

我很不希望，你指的是这部分。

3、按照ecma的回复，This all depends somewhat on the implementation, but in a typical and
reasonable implementation the representation of a function has two
parts, the (compiled) code and the environment. 

咱们姑且认为这个回复是正确的，那么也就是存在两个部分，编译后的代码，和环境。在编译后的代码中，确实，每个function

确实只有一个，而且也只能有一个。但是对于环境来说，却并非如此。

In practice, implementations optimize this when
they can, but in your example they can't, because the two environments
that are created for the calls to "Light" live longer than the calls
do (because they are captured when the function objects are created).

也就是说，实现只在他们可以的时候进行优化，而在有些情况下，实现无法做到优化，在我发给他们的例子中，由于，调用Light后create的东西比调用本身活的久。

再来谈你的join的问题：

Step 1 allows an implementation to optimise the common case of a function A that has a nested function B
where B is not dependent on A. In this case the implementation is allowed to reuse the same object for B
instead of creating a new one every time A is called. Step 13 makes this optimisation optional; an
implementation that chooses not to implement it will go to step 2.
For example, in the code