在 ECMAScript 5 之后重新审视扩展原生原型答案

【问题标题】：Revisiting extending native prototypes after ECMAScript 5在 ECMAScript 5 之后重新审视扩展原生原型
【发布时间】：2012-08-02 16:29:28
【问题描述】：

最近，鉴于 ECMAScript 5 中定义属性的变化，我重新审视了我们是否可以安全地扩展原生 JavaScript 原型的问题。事实上，一直以来我都扩展了 Array 和 Function 之类的原型，但出于显而易见的原因，我避免使用 Object 这样做。在 Jasmine 的单元测试中，通过将 Object.prototype 规范添加到我自己的个人框架的规范中，使用不可枚举的函数扩展 Object.prototype 似乎是安全的。然而，像“类型”属性这样的数据属性，带有执行任何异常处理的 getter/setter 会产生意想不到的后果。仍然存在与其他库发生冲突的可能性——尽管在我的工作中，这几乎从未出现过。尽管如此，只要函数不可枚举，看起来扩展 Object.prototype 是安全的。

你怎么看？现在扩展 Object.prototype 是否安全？请讨论。

【问题讨论】：

我会广泛同意使用不可枚举的描述符扩展对象是安全的。至于冲突，如果命名空间适当，这些冲突可以最小化，即您可以添加String.prototype.myExtensions.someMethod 而不仅仅是String.prototype.someMethod。
用另一个对象扩展一个对象，有点像合并函数，会非常有用。
多年过去了，现在有一个关于Modifying built-in prototypes in ES6的问题:-)

标签： javascript ecmascript-5

【解决方案1】：

扩展 JavaScript 原生对象可能会变得更安全一些，但仍然存在许多冲突问题。一般来说，除非您扩展对象以支持最新标准的标准化行为，否则引入包装器确实会更安全 - 当您是唯一可以控制的人时，以正确的方式做事会容易得多。

谈到环境原生的对象（DOM 元素和节点，AJAX 的东西），新的 JS 标准仍然没有给出，并且可以说，不能保证与这些对象的任何交互除了他们的接口标准中定义的内容。永远不要忘记它们可以通过许多不同的脚本引擎访问，因此不需要针对一种特定语言的怪癖进行定制 - JS。因此，不扩展这些的建议仍然有效。

【讨论】：

在选择“获胜者”之前，我打算等待一段时间，但我认为包装器或“装饰器”仍然是最安全的做法。碰撞尤其令人担忧。此外，有人会问，为什么要冒险？

【解决方案2】：

确定的、绝对的答案是……

“这取决于。” :)

扩展任何内置的 JavaScript 对象可能是完全安全的，也可能是一场彻底的灾难。这取决于您在做什么以及如何做。

使用聪明的做法和常识并测试它的地狱。

【讨论】：