为什么没有将ES5 Object方法添加到Object.prototype？ [英] Why were ES5 Object methods not added to Object.prototype?
问题描述
ES5添加了数字 .github.com /＃x15.2.3.9rel =noreferrer>方法到对象，这似乎打破了JavaScript的语义一致性。
ES5 added a number of methods to Object, which seem to break the semantic consistency of JavaScript.
例如，在此扩展之前，JavaScript API总是围绕 on 对象本身进行操作;
For instance, prior to this extension, the JavaScript API always revolved around operarting on the object itself;
var arrayLength = [].length;
var firstPosInString = "foo".indexOf("o");
...其中新的Object方法如下;
... where as the new Object methods are like;
var obj = { };
Object.defineProperty(obj, {
value: 'a',
writable: false
});
...当以下内容更加符合要求时：
... when the following would have been much more conformative:
var obj = { };
obj.defineProperty({
value: 'a',
writable: false
});
任何人都可以冷静我的好奇心，为什么会这样？是否有任何代码片段会破坏？标准委员会是否就他们为何选择这种方法进行了公开讨论？
Can anyone cool my curiosity as to why this is? Is there any code snippets that this would break? Are there any public discussions made by the standards committee as to why they chose this approach?
推荐答案
这一切都在很好地解释了建议ECMAScript 3.1静态对象函数：用例和基本原理文档（pdf）作者：Allen Wirfs-Brock本人（ES5规范的编辑，以及TC39的成员）。
This is all explained very nicely in "Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale" document (pdf) by Allen Wirfs-Brock himself (editor of ES5 spec, and a member of TC39).
我建议阅读所有内容。它非常简短，容易消化，并且可以很好地了解这些ES5添加背后的思维过程。
I would suggest to read all of it. It's pretty short, easily digestible, and gives a nice glimpse of the thought process behind these ES5 additions.
但引用相关部分（强调我的）：
But to quote relevant section (emphasis mine):
在选择
建议的API之前，许多替代API设计被视为。在考虑替代方案的过程中，我们b $ b b开发了一套非正式指导方针，我们在考虑替代方案的b $ b时采用了这些指导方针。这些指南是：
A number of alternatives API designs were considered before the proposed API was chosen. In the course of considering alternatives we developed a set of informal guidelines that we applied when considering the alternatives. These guidelines are:
- 干净地分隔元和应用层。
- 尽量减少API表面积（即方法的数量和参数的复杂性）。
- 关注命名和参数设计的可用性。
- 尝试重复应用设计的基本元素。
- 如果可能，启用程序员或实现以静态优化API的使用。
- Cleanly separate the meta and application layers.
- Try to minimize the API surface area (i.e., the number of methods and the complexity of their arguments).
- Focus on usability in naming and parameter design.
- Try to repeatedly apply basic elements of a design.
- If possible, enable programmers or implementations to statically optimize uses of the API.
[...]
以下是一些被视为导致
的替代方案选择的设计。
Here are some of the alternatives that were considered that lead to the selected design.
根据现有的标准方法Object.prototype.propertyIsEnumerable已经是
的示例，显而易见的初步想法是
add另外propertyIs ...在Object.prototype上查询
的方法，其他属性和一组并行的属性更改方法。
The obvious initial idea, following the example of the already existing standard method Object.prototype.propertyIsEnumerable, was to add additional "propertyIs..." query methods on Object.prototype for the other attributes and a parallel set of attribute changing methods.
[...]
当我们考虑这种方法时，有很多关于我们不喜欢的
，这似乎与上述API设计相反
指南：
As we considered this approach there were a number of things about it that we didn’t like and that seemed contrary to the above API design guidelines:
- 合并而不是分隔元层和应用层。作为Object.prototype上的方法，方法将成为程序中每个应用程序对象的公共
接口的一部分。因此，每个开发人员都需要
来理解，而不仅仅是图书馆设计师。
- It merges rather than separates the meta and application layers. As methods on Object.prototype the methods would be part of the public interface of every application object in a program. As such, they need to be understood by every developer, not just library designers.
[...]
这篇关于为什么没有将ES5 Object方法添加到Object.prototype？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
