Не использовать getPrototypeOf?

В это видео (около 31 минуты), Крокфорд говорит, что они (выступая от имени комитета ECMAScript) рекомендуют не использовать Object.getPrototypeOf. Его объяснение состояло в том, что оно не предназначалось для среднего разработчика, но предназначалось для таких вещей, как Caja, которые могут удалить его из Object, чтобы вы не могли его получить.

Крокфорд иногда может быть довольно самоуверенным в своих взглядах на то, как использовать JS (не все ли мы?), поэтому мне интересно, действительно ли это полная рекомендация комитета ES или если это только один из Crockford личные мнения. Кто-нибудь читал официальное выражение, предупреждающее об использовании Object.getPrototypeOf? Это действительно звучит как обломка для меня:(, но я не вижу никакой информации о предупреждении страницы MDN против ее использования, и я ожидаю, что уведомление будет там, если это действительно было плохой идеей.

Ответ 1

Его рассуждения невероятно бедны. Он (и Object.getOwnPropertyNames) не был просто добавлен для использования Caja и подобных. Также Caja просто не удаляет их! Caja перехватывает Object.getOwnPropertyNames, чтобы реализовать WeakMap (который мой обтекатель также), и насколько я могу судить, это не изменить getPrototypeOf. На самом деле это было бы бессмысленно, потому что Object.getPrototypeOf(o) - это то же самое, что o.__proto__, которое реализовано в каждом браузере, кроме IE, и не может (в настоящее время) быть выключено. Это означает, что единственными браузерами, которые будут удалять Object.getPrototypeOf from, могут быть IE9 и IE10.

Причина, по которой я полагал, что он даст, состоит в том, что некоторые из этих функций в основном предназначены для использования типами "авторский тип библиотеки". Это то, что обычно считают/считают люди, связанные с процессом спецификации, и я считаю, что это законное требование; дескрипторы/атрибуты свойств и другие API уровня мета-уровня - это более сложные функции, которые могут быть громоздкими в использовании и, как правило, требуют более полного владения языком для правильного использования. Тем не менее, это все равно не будет общей рекомендацией "не использовать их". Это более точное утверждение не было даже аргументом, который он сделал, однако.

Одна дополнительная заметка о видео, в которой он сделал неправильное выражение. Он сказал, что атрибуты свойства (перечислимые, настраиваемые, доступные для записи) были неизменными после установки. Это неверно. Их можно изменить, пока configurable истинно. Когда он установлен в значение false, атрибуты становятся замороженными (и это свойство не может быть удалено).

Изменить: после проведения исследований я нашел некоторые из оригинальных обсуждений этой функции и других функций объекта. Сводка, как я понимаю, следует.

Была высказана озабоченность по поводу последствий безопасности для доступа к [[Prototype]] объекта. Однако эти проблемы были более полно и надлежащим образом рассмотрены с помощью таких вещей, как Object.freeze, а также частично устранены (и причина), что эти функции живут на объекте как статические функции (удаляются в одном месте), а не на Object.prototype или магически на каждом объекте, таком как Прото, было исторически.

Еще одна проблема заключалась в нарушении инкапсуляции

Верно, что proto или getPrototypeOf разрушает барьер инкапсуляции объекта и показывает детали реализации, которые, возможно, были предназначены для скрытия. То же самое можно сказать и о предлагаемой функции getProperty, которая, среди прочего, предоставляет наблюдателю доступ к функциям, реализующим свойство getter/setter. В общем, это характер рефлексии. -Аллен Вирфс-Брок

Одна из проблем, затронутых в ходе реализации, заключалась в том, чтобы разоблачить детали реализации (в основном это проблема, связанная с тем, как работает DOM, с тех пор она была устранена изменениями в использовании DOM множественного наследования и перехода на WebIDL).

С другой стороны, предоставление рефлексивного доступа к прототипу объекта вредно для совместимости, поскольку оно препятствует внедрению промежуточных прототипов, не нарушая работу Интернета. Рассмотрим пример того, что у вас есть только Numbers и позже совместимо вводить более конкретные подкиды Numbers. -Waldemar Horwat

Эта проблема также связана с другой, упомянутой в списке рассылки script, о том, что внутренние скрытые прототипы являются одним и тем же кросс-фреймом. Эта проблема также является исторической с ES5 (и IE8), где было решено и реализовано, что каждый кадр должен создавать свой собственный набор прототипов DOM. Таким образом, скрытие прототипов по этой причине больше не было связано с тем, что ES5 был официально опубликован.

Консенсус, который я вижу, не следует объяснению Крокфорда. Скорее всего, это просто повторение его собственного мнения.

Таким образом, отсутствие рефлексивного доступа к прототипу объекта действительно не обеспечивает реальной безопасности, оно просто делает некоторые полезные задачи менее удобными. -Аллен Вирфс-Брок

Я согласен с вами здесь в целом, и хорошо слышать, что отражение не является врагом "реальной безопасности". -Брендан Эих

Отправной точкой для этого является Предлагаемый ECMAScript 3.1 Функции статического объекта: использование случаев и обоснование(написано Крокфордом и другими на TC39). Следующим шагом к этому, где я рисую цитаты из, является этот дискуссионный поток. В частности этот пост и этот пост.