javascript - 不使用 getPrototypeOf？

Question

在this video (大约 31 分钟)，Crockford 说他们(代表 ECMAScript 委员会发言)建议不要使用Object.getPrototypeOf。他的解释是，它并不是真正适用于普通开发人员，而是适用于像 Caja 这样的东西，它可能会从 Object 中删除它以防止您访问它。

Crockford 有时会在他对如何使用 JS 的观点上非常固执己见(我们都不能吗？)，所以我想知道这是否真的是 ES 委员会的完整建议，或者它是否只是 Crockford 的建议之一个人意见。有没有人读过任何官方声明警告不要使用 Object.getPrototypeOf？这对我来说真的听起来很糟糕 :(，但我没有在 MDN 页面上看到任何警告不要使用它的信息，如果这真的是个糟糕的主意，我希望那里有一个通知。

Answer 1

他的推理非常糟糕。它(和 Object.getOwnPropertyNames)不是简单地添加用于 Caja 和类似的。 Caja 也不会简单地删除它们! Caja 拦截 Object.getOwnPropertyNames 以实现 WeakMap(my shim 也是如此)并且据我所知它不会修改 getPrototypeOf。实际上，无论如何它都是毫无意义的，因为 Object.getPrototypeOf(o) 与 o.__proto__ 是一样的，它在除 IE 之外的所有浏览器中都实现并且不能(当前)被关闭。这意味着从中删除 Object.getPrototypeOf 会产生任何影响的浏览器只有 IE9 和 IE10。

我认为他会给出的原因是其中一些函数主要供“库作者”类型的用法使用。这是参与规范过程的人普遍相信/所说的话，我相信这是一个合法的主张；属性描述符/属性和其他“元”级 API 是更高级的功能，使用起来可能很麻烦，并且通常需要更完整的语言掌握才能正确使用。但是，这仍然不等于“不要使用它们”的笼统建议。不过，这种更准确的说法甚至不是他提出的论点。

关于视频的额外说明，他在视频中做出了错误的陈述。他说属性属性(可枚举、可配置、可写)一旦设置就不可更改。这是不正确的。只要 configurable 为真，这些都可以更改。一旦设置为 false，属性将被卡住(属性也不可删除)。

---

编辑:经过研究，我找到了一些关于此功能和其他对象功能的原始讨论。据我了解，摘要如下。

有人担心能够访问对象的 [[Prototype]] 的安全隐患。然而，这些问题通过 Object.freeze 之类的东西得到了更充分和适当的解决，并且也部分解决了(也是一个原因)这些函数作为静态函数存在于 Object 上(在一个位置可删除)而不是 Object.prototype 或神奇地在历史上像 proto 这样的每个对象上。

提出的另一个问题是破坏封装

It's true that proto or getPrototypeOf breaks an object's encapsulation barrier and reveals implementation details that perhaps were intended to be hidden. The same could be said about the proposed getProperty function which, among other things, gives an observer access to the functions that implement a getter/setter property. In general, that's the nature of reflection. -Allen Wirfs-Brock

从实现端提出的一个问题是公开实现细节(主要是 DOM 工作方式引起的问题，此后已通过更改 DOM 对多重继承的使用和向 WebIDL 的过渡得到解决)。

On the other hand, providing reflective access to an object's prototype is harmful to compatibility because it prevents implementations from introducing intermediate prototypes without breaking the web. Consider the example of having just Numbers and later compatibly introducing more specific subkinds of Numbers. -Waldemar Horwat

这个问题也与脚本协调邮件列表中提到的另一个问题有关，即内部隐藏原型(prototype)是相同的跨框架。这个问题在 ES5(和 IE8)中也是历史性的，它决定并实现了每个框架必须实例化它自己的一组 DOM 原型(prototype)。因此，在 ES5 正式发布时，出于这个原因隐藏原型(prototype)已不再适用。

---

我看到的共识并不遵循 Crockford 的解释。大多数情况下，这似乎只是对他自己观点的重申。

In summary, not providing reflective access to an object's prototype doesn't really provide any real security, it just makes some useful tasks less convenient. -Allen Wirfs-Brock

---

I agree with you here in general, and it's good to hear that reflection is not the enemy of "real security". -Brendan Eich

起点是Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale (由 Crockford 等人在 TC39 上编写)。我引用的后续内容是 this es-discuss thread .具体this post和 this post .