为什么没有将ES5 Object方法添加到Object.prototype？

Question

ES5添加数量的方法来Object,这似乎打破的JavaScript的语义的一致性.

举例来说,在此之前的扩展,JavaScript API的身边总是围绕operarting 对对象本身;

var arrayLength = [].length;
var firstPosInString = "foo".indexOf("o");

...新的Object方法就像;

var obj = { };
Object.defineProperty(obj, {
    value: 'a',
    writable: false
});

......当以下内容更加符合时:

var obj = { };
obj.defineProperty({
    value: 'a',
    writable: false
});

任何人都可以冷静我的好奇心,为什么会这样？是否有任何代码片段会破坏？标准委员会是否就他们选择这种方法的原因进行了公开讨论？

Answer 1

这一点在Allen Wirfs-Brock本人(ES5规范编辑和TC39成员)的"拟议的ECMAScript 3.1静态对象函数:用例和原理"文档(pdf)中得到了很好的解释.

我建议阅读所有内容.它非常短,易于消化,并且可以很好地了解这些ES5添加背后的思维过程.

但引用相关部分(强调我的):

在选择提议的API之前,已考虑了许多替代API设计.在考虑替代方案的过程中,我们制定了一套我们在考虑替代方案时应用的非正式指导方针.这些准则是:

• 干净地分离元层和应用程序层.
• 尽量减少API表面积(即方法的数量和参数的复杂性).
• 专注于命名和参数设计的可用性.
• 尝试重复应用设计的基本元素.
• 如果可能,使程序员或实现能够静态地优化API的使用.

[...]

以下是一些被认为是导致所选设计的替代方案.

根据现有标准方法Object.prototype.propertyIsEnumerable的示例,明显的初步想法是在Object.prototype上为其他属性和一组并行的属性更改方法添加额外的"propertyIs ..."查询方法.

[...]

当我们考虑这种方法时,我们不喜欢它的一些事情,这似乎与上述API设计指南相反:

• 它合并而不是分离元层和应用层.作为Object.prototype上的方法,这些方法将成为程序中每个应用程序对象的公共接口的一部分.因此,每个开发人员都需要了解它们,而不仅仅是图书馆设计师.

[...]