Object.prototype - Verboten?

Ответ 1

Дело в том, что это прекрасно, пока вы знаете, что делаете и каковы издержки. Но это большой "if". Некоторые примеры затрат:

• Вам нужно провести тестирование обширное с любой библиотекой, которую вы хотите использовать, с средой, которая увеличивает Object.prototype, потому что подавляющее соглашение заключается в том, что пустой объект не будет перечислить свойства. Добавляя перечислимое свойство в Object.prototype, вы делаете это соглашение ложным. Например, это довольно часто:

  var obj = {"a": 1, "b": 2};
  var name;
  for (name in obj) {
      console.log(name);
  }
  

  ... с подавляющим соглашением, что будут отображаться только "a" и "b", а не "getProperties".

• Любой, кто работает над кодом, должен быть обучен тому, что это соглашение (выше) не соблюдается.

Вы можете уменьшить это, используя Object.defineProperty (и аналогичный), если он поддерживается, но будьте осторожны, даже в 2014 году браузеры, такие как IE8, не поддерживают он по-прежнему остается в значительном объеме (хотя мы можем надеяться, что это быстро изменится, когда XP официально EOL'd). Это связано с тем, что с помощью Object.defineProperty вы можете добавить неперечислимые свойства (те, которые не отображаются в циклах for-in), и поэтому у вас будет намного меньше проблем (в этот момент, вы в первую очередь обеспокоены конфликтами имен) — но он работает только в системах, которые правильно реализуют Object.defineProperty (и правильная реализация не может быть "подгонка" ).

В вашем примере я бы не добавил getProperties в Object.prototype; Я бы добавил его в Object и принял объект в качестве аргумента, например ES5 для getPrototypeOf и тому подобного.

Имейте в виду, что библиотека Prototype получает много флаков для расширения Array.prototype из-за того, как это влияет на циклы for..in. И это просто Array (который вы не должны использовать for..in в любом случае (если вы не используете защитник hasOwnProperty и, скорее всего, String(Number(name)) === name).

... если люди V8 делают это, кто я такой, чтобы сказать, что они неправы?

На V8 вы можете положиться на Object.defineProperty, потому что V8 - полностью совместимый с ES5 движок.

Обратите внимание, что даже если свойства не перечислимы, возникают проблемы. Несколько лет назад прототип (косвенно) определил функцию filter на Array.prototype. И он делает то, что вы ожидаете: вызывает функцию итератора и создает новый массив на основе элементов, которые выбирает функция. Затем появился ECMAScript5 и определил Array.prototype.filter, чтобы сделать то же самое. Но там руб: Много то же самое. В частности, подпись функций-итераторов, вызываемых по-разному (ECMAScript5 содержит аргумент, который не использовал Prototype). Это могло быть намного хуже, чем это (и я подозреваю, но не могу доказать, что TC39 знал о прототипе и намеренно избегал слишком большого конфликта с ним).

Итак: Если вы собираетесь это сделать, будьте в курсе рисков и затрат. Уродливые, крайние ошибки, с которыми вы можете столкнуться в результате попыток использовать готовые библиотеки, действительно могут стоить вам времени...

Ответ 2

Если фреймворки и библиотеки, как правило, делали то, что вы предлагаете, очень скоро произойдет, что две разные структуры определят две разные функции как один и тот же метод Object (или Array, Number... или любой существующих прототипов объектов). Поэтому лучше добавить такие новые функции в свое собственное пространство имен.

Например, представьте себе, что у вас будет библиотека, которая будет сериализовать объекты в json и библиотеку, которая будет сериализовать их в XML, и оба будут определять их функциональность как

Object.prototype.serialize = function() { ... }

и вы сможете использовать только тот, который был определен позже. Так что лучше, если они этого не сделают, а вместо этого

JSONSerializingLibrary.seralize = function(obj) { ... }
XMLSerializingLibrary.seralize = function(obj) { ... }

Также может случиться так, что новая функциональность определена в новом стандарте ECMAscript или добавлена ​​поставщиком браузера. Представьте себе, что ваши браузеры также добавят функцию serialize. Это снова вызовет конфликт с библиотеками, которые определяют одну и ту же функцию. Даже если функциональность библиотек была такой же, как и встроенная в браузер, интерпретируемые функции script переопределили бы нативную функцию, которая, по сути, была бы быстрее.

Ответ 3

См. http://www.websanova.com/tutorials/javascript/extending-javascript-the-right-way

Что касается некоторых, но не всех, возражений. Возражение о разных библиотеках, создающих методы конфлирования, можно устранить, создав исключение, если в Object.prototype уже присутствует метод, специфичный для домена. Это, по крайней мере, даст предупреждение, когда произойдет это нежелательное событие.

Вдохновленный этой записью, я разработал следующее, которое также доступно в комментариях цитируемой страницы.

!Object.implement && Object.defineProperty (Object.prototype, 'implement', {
  // based on http://www.websanova.com/tutorials/javascript/extending-javascript-the-right-way
  value: function (mthd, fnc, cfg) { // adds fnc to prototype under name mthd
      if (typeof mthd === 'function') { // find mthd from function source
        cfg = fnc, fnc = mthd;
        (mthd = (fnc.toString ().match (/^function\s+([a-z$_][\w$]+)/i) || [0, ''])[1]);
      }
      mthd && !this.prototype[mthd] && 
        Object.defineProperty (this.prototype, mthd, {configurable: !!cfg, value: fnc, enumerable: false});
    }
});

Object.implement (function forEach (fnc) {
  for (var key in this)
    this.hasOwnProperty (key) && fnc (this[key], key, this);
});

Я использовал это прежде всего, чтобы добавить стандартную определенную функцию в реализацию, которая их не поддерживает.