是否应该避免通过符号扩展内置的Javascript原型？ [英] Should the extension of built-in Javascript prototypes through symbols also be avoided?

问题描述

内置的主要意见 Javascript原型不应该被扩展（或以任何方式改变）：

  Array.prototype.empty = function（）{return this .length === 0; } //不要尝试
  

此规则是否也适用于ES2015符号？

  const empty = Symbol（empty）; 
 Array.prototype [empty] = function empty（）{return this.length === 0; } 
  

由于符号 code> string （原始，不可变）和对象（身份）根据定义，没有对象属性命名冲突。 >

正常对象反射不受符号影响：

  Object.getOwnPropertyNames（Array .prototype）.indexOf（ 空）; // -1 
  

但是ES2015反射与 Reflect.ownKeys（Array.prototype ）是

所以这个问题主要是关于我们如何使用 Reflect.ownKeys 和 Object.getOwnPropertySymbols 。

解决方案

是的。

不要修改你不拥有的东西规则有两个部分：

1. 您可能会导致姓名冲突，您可以 可以打破代码。

   
   
   

   通过触摸您不拥有的东西，您可能会意外覆盖某些其他图书馆使用的东西。这将以意想不到的方式破解他们的代码。




2. 您可以创建严格的依赖关系，他们可以打破您的代码

   
   
   

   通过将代码绑定到其他对象上，如果它们发生了重大变化（例如删除或重命名类），则代码可能会突然中断。

使用符号会避免＃1，但是你仍然遇到＃2。通常不鼓励类之间的紧密依赖关系。如果另一个类是冻结，你的代码仍然会中断。 答案 这个问题仍然适用，只是因为略有不同的原因。

您想要关注松散绑定< a>您的依赖关系来支持更好的测试（松散绑定更容易模拟）和更容易的维护（一些明显的连接更容易记录和更新）。

要清楚：名称冲突只是由严格依赖关系引起的问题的症状。

It is the predominant opinion that built-in Javascript prototypes should not be extended (or altered in any way):

Array.prototype.empty = function () { return this.length === 0; } // don't try that

Does this rule also apply to ES2015 symbols?

const empty = Symbol("empty");
Array.prototype[empty] = function empty() { return this.length === 0; }

Since symbol is a mix of string (primitive, immutable) and object (identity) there can be no object property naming conflicts by definition.

Normal object reflection is not affected by symbols:

Object.getOwnPropertyNames(Array.prototype).indexOf("empty"); // -1

But ES2015 reflection with Reflect.ownKeys(Array.prototype) is.

So this question is mainly about how we'll use Reflect.ownKeys and Object.getOwnPropertySymbols in the future.

解决方案

Yes.

There are two parts to the "don't modify something you don't own" rule:

1. You can cause name collisions and you can break their code.

   By touching something you don't own, you may accidentally overwrite something used by some other library. This will break their code in unexpected ways.

2. You can create tight dependencies and they can break your code.

   By binding your code so tightly to some other object, if they make some significant change (like removing or renaming the class, for example), your code might suddenly break.

Using symbols will avoid #1, but you still run into #2. Tight dependencies between classes like that are generally discouraged. If the other class is ever frozen, your code will still break. The answers on this question still apply, just for slightly different reasons.

You want to focus on loosely binding your dependencies to support better testing (loose bindings are easier to mock) and easier maintenance (a few obvious connections are easier to document and update).

To be clear: the name collisions are just a symptom of the problems caused by tightly-bound dependencies.

这篇关于是否应该避免通过符号扩展内置的Javascript原型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！