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

我没有混淆equated和equal的含义，前者译为“相等性”，后者译为“相等”，我认为足够精准了。对于相等和等价二者的不同，对于英文来说可以考据，对于中文来说只是个心里上的模糊的感觉，没有必要在这里咬文嚼字，把一个简单的英文单词意为“视作等同”四个字更是不合适的；再者，既然你没有因此“混淆”，我想我的目的已经达到了，毕竟这里不是翻译论坛。
而且，我也没有说过“相同”一词，谈到比较问题时全部使用了 === 符号。您老真的很客气呀。

这是水平低下的实现给我的误导。我当然对识别相等函数只须定位很清楚，但无法解释为什么时间的变化，疑心是否作了更高级的优化，所以才会作出这样的猜测。如果你认为那是一个笑话，我表示赞同；但这与“混淆了equated和equal的含义”没有丝毫联系。我知道你的想法：你认为我是因为没有充分理解规范中的函数相等，当成是源代码相等，我说的没错吧？希望你不要如此乐于先假定被人什么都不懂，说错话了就是什么都错了，然后列出别人除了你认为正确的观点之外的项目，顺手给被人戴上“乱作一团”的帽子。

PS: 我不赞同在公共论坛上互相诘难而非互相学习。到目前为止，我还没有要和你较量一下辩论才能和逻辑分析能力的意思。

keshin的代码，如下：

   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)  

看看代码，这里根本不存在重复使用{alert("bingo")}这个函数体的情况，Light构造函数里做的只不过是assign一个引用而已。所以这里根本不存在是否equated的问题，因此也不存在任何与joined object相关的问题。

然后，让我们检查一下你的论证逻辑。

你的原话：


我们顺着你的逻辑看一下。

你的因果关系是：

test符合“同生共死”的条件 => 函数可以被join => 运算===的结果为true。

然而规范说的是什么？

1. Equal比较算法的一个步骤是：Return true if x and y refer to the same object or if they refer to objects joined to each other
也就是：

x和y指向同一对象 => ===返回true
x和y是互相joined的 => ===返回true

2. When two or more Function objects are joined, they have the following special behaviours: ...
也就是：

两个函数对象被joined => 它们的属性是“同生共死”
两个函数对象被joined => ===结果为true

3. If there already exists an object E ..., and if that call to this section's algorithm was given a FunctionBody that is equated to the FunctionBody given now, then ... At the implementation's discretion, go to either step 2 or step 14.
也就是：

两个FunctionBody是equated的 => 允许joined

我想在此出没的，都身为程序员，或曾为程序员，基本的逻辑推理肯定ok，相信什么必要条件、充分条件、否命题、逆命题之类的，都难不倒大家。所以在此我就把找出Lich_Ray在上文中的逻辑错误，作为一个逻辑练习留给各位读者了。

另一个类似的习题是：


读者可自行解决此问题，或者回顾一下我前面的回帖（已收入我的blog http://hax.iteye.com/admin/show/103298），因为该回帖中，我也提出了对于ECMA规范的质疑，有兴趣的同志可再做讨论。

Equated怎能译作相等性呢，那你准备把Equality怎么翻？

中文怎么就模糊了？你模糊不等于别人就也模糊。中文的“相等”和“等价”完全可以做到让读者概念清晰。而你的“相等”和“相等性”，能清晰么？

“视作等同”，我是在释义，不是在翻译。

你又说没说过“相同”，ok，我不客气，直接拿你的原文：



当然，一者，此段引文乃是keshin所引，我并不知道你的出处。再者，你后面似乎也意识到自己的问题，所以生造了一个所谓“相等性测试”的名词来解说。

下面，你倒是说说是哪个“水平低下的实现”误导了你呢？后面你的解释“但无法解释为什么时间的变化，疑心是否作了更高级的优化，所以才会作出这样的猜测”，不知所云，麻烦你用大家都看得懂的中文写出来，不要玩意识流好不好。。。

我认为你在前面的帖子中混淆了equated和equal的含义，是根据你的行文和解说，按照我对文字的理解力，所推论出来的。你如果不承认有混淆概念，或者认为说你的文字超出了我的理解范畴，那我也无话可说。还有你不要给我戴上“乱给别人戴帽子”的帽子，我只不过说出事实而已。你去看看你前面所有的文章里面，对“相等”、“相等性”、“相同”、“同一”的使用。即使你在后面的回复中越来越注意做到自圆其说，但是这样的词汇运用无论如何都是会造成混乱的。

最后，我也无意与你较量，我是希望能把问题讨论清楚。如我所说，ECMA规范是出了名的难读。所以理解不到位是很正常的，我也不例外，所以我说了，我对于规范的质疑，是需要向BE等人去求证的。

最后，在前面的回帖中，我最多是揶揄一下你。。。不过好像这里的很多人（包括管理员）经不起揶揄。希望不要搞着搞着就被弄成了隐藏帖。比较而言，我以前写过系列文章批评aimingoo对ECMA规范的理解有问题。但是我们之后还是能很好的一起讨论，甚至他还介绍我进入我之前的公司。做技术的人，当是如此。

补充一点我对于讨论的意见（特别请管理员看看），我这里说Lich_Ray的一些理解不正确，或者逻辑有问题，是仅局限于特定范畴和特定问题的。请各位读者，包括Lich_Ray同志自己，千万不要无端扩大，认为我是在说Lich_Ray这个人的逻辑思维能力有问题。

我所有的讨论，只限于从他行文中所表达出来的东西，并按照我的个人理解，赞同或批评（因为此处禁止“顶”、“赞”这样的，所以基本上赞同的部分我就略去了，而集中于批评）。

我所有的批评，都只限于可观测的部分上——我也不是别人肚里的蛔虫，也许我所批评的，只是由于他部分外在的表达不够清晰，或我的理解力有限，或我们之间语境的错位。以此观之，我说他的词汇运用乱做一团，只是就我观察到的情况，作出评判。

我认为，这样一种批评的权力，显然是不能被剥夺的，更不好说是乱扣帽子。当然，可以反驳说，实际上我的词汇运用是有序的，只是你不理解而已。继而大家有理有序的讨论，以求同存异。

所以，我是针对可观测的部分发表意见。如有逾越，比如作出一些推测，或为推敲问题的深层原因，或属修辞需要，切莫太过敏感哦！

说的很好，大家鼓掌。
首先，你说过“事实上，我所知的所有实现，都没有像规范所描述的 join 行为。”；也注意到了，规范只给出了join 的定义而没有给出具体算法。
Joined 是规范中使用的一个形容词，而你把 join 理解为了一个动词，一种行为。你的依据是：

你认为这句话是在说：如果两个对象被"结合"，它们...
但你恐怕没有注意到，这一章的标题是 Joined Objects 而不是 Joining Objects。也许你还没有注意到，下文的 When two or more Function objects are joined 为什么不是 were joined。你注意到了这个：Return true if x and y refer to the same object or if they refer to objects joined to each other. 但别忘了，在英语中使用 joined to each other 不可替代 that were joined each other；这里“多出来“的 to 是“对于”的意思。我以为没有人会就这里的因果问题发难而放松了“警惕”，一直没有提这个问题。
所以，下面说的一切都是 joined 的定义性描述，更多的是“因”，而不是“果”。但是，你单方面认为规范的逻辑思路是：

如果你英文看对了，你的推理确实一点问题没有。还是那句话，我一开始以为大家都是好人，不会有人在这种事情上斤斤计较，很多地方没有太关心这个“逻辑问题”；现在既然有，那我也只好奉陪了。
知道了这一点，下面我也不想多说了。写这样的东西可能会让人反感，因为已经和话题彻底没了关系。 像这样的话，

还有这个，

这个

私下说说也就罢了。搬到这儿来，没意义。讨论的目的是为了让真理越来越清晰，现在已经越来越清晰了，还折腾那些老皇历干嘛呢？

比较欣赏你的行事作风^_^向你学习！

更新：

我发了邮件到es4-discuss邮件列表上（讨论ecmascript4的官方列表）。

有了一些讨论，我这里不一一复述。仅说一下大概。

经过一些讨论，大家都认为joined function是有问题的，主要的问题是可能导致语义不一致的情况出现。有人写了一个比我的例子更有力的例子：


function f() {
  function g() {}
  if (!("x" in g)) g.x = 12;
  g.x += 10;
  return g.x;
}

f();
f();

无论从那方面看，所有人都一致认可，上述的对g的functionBody的用法是equated的，因此可以成为joined function，结果就是第一次返回22，而第二次返回22（不join）或32（join）居然都是符合规范的。

对此，Brendan Eich（js之父，规范制定者之一）回复P T Withington（open laszlo的js引擎的开发者）说：


On Jul 31, 2007, at 5:41 AM, P T Withington wrote:

> Indeed.  I was suggesting that the spec was broken; that it meant to
> prescribe an optimization to avoid unnecessary closures, but that it
> got it wrong (perhaps because it overlooked the mutability of the
> function object itself?).  Surely backwards compatibility should not
> trump correctness?  You don't want to have to force users to contrive
> to create a closure just to be able to add properties to a function?

No, none of that (breaking backward compatibility, requiring closures
for mutability) was desired.

I wasn't around for Edition 3 except for one or two meetings (pitched
sharp variables and uneval/toSource), but I talked to Waldemar about
this at some point. The goal was to allow an optimization that would
be implementation dependent. I believe mutability was forgotten. So
we should just remove all this joined function language.

至于我提出的其他观点，尚没有结论。

哎，js牛气冲天。

我是新来的, 就大家的帖子所见, 无论对错, hax兄弟和LZ都很好, 至于有些人研究/发言/交流的态度, 确实和年龄挂钩, 不过现在的孩子知识水平确实也挺赞的, 呵呵

完全看不懂啊 这叫一个汗！！！！！！！！ 不过看样子子都是 高手 论据几乎都来自官方规范或与官方的邮件交流 这份认真的态度使值得我们每一个人学习的