Question

ES5向Object添加了number methods，这似乎打破了JavaScript的语义一致性。

例如，在此扩展之前，JavaScript API始终围绕在对象本身上操作;

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的成员）在"Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale" document（pdf）中对此进行了很好的解释。

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

但引用相关部分（强调我的）：

之前的许多替代API设计被视为   建议的API被选中。在考虑替代品的过程中我们   制定了一套我们在何时应用的非正式指南   考虑替代方案。这些指导原则是：


干净地分隔元图层和应用程序图层。

尽量减少API表面积（即方法的数量和参数的复杂性）。

专注于命名和参数设计的可用性。

尝试重复应用设计的基本元素。

如果可能，请启用程序员或实施以静态优化API的使用。


[...]

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

明显的初步想法，遵循已经的例子   现有的标准方法Object.prototype.propertyIsEnumerable，是   在Object.prototype上添加额外的“propertyIs ...”查询方法   其他属性和一组并行的属性更改方法。

[...]

当我们考虑这种方法时，有很多事情要做   我们不喜欢，这似乎与上述API设计相悖   准则：


合并而不是分隔元层和应用层。作为Object.prototype上的方法，方法将成为公众的一部分   程序中每个应用程序对象的接口。因此，他们需要   每个开发人员都要理解，而不仅仅是图书馆设计师。


[...]

Answer 2

JavaScript API总是围绕对象本身进行操作;

这不正确。例如。 JSON和Math始终拥有自己的方法。没有人这样做：

var x = 0;
x.cos(); // 1.0
({"a":[0,1],"p":{"x":3,"y":4}}).toJSON();

网上有很多关于为什么延长Object.prototype是件坏事的文章。是的，它们是关于客户端代码，但可能这对于内置方法也是有害的。

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

2 个答案: