Почему методы объекта ES5 не были добавлены в Object.prototype?

Question

ES5 добавил число из методов в Object, что, по-видимому, нарушает семантическую согласованность JavaScript.

Например, до этого расширенияJavaScript API всегда вращался вокруг работы на самого объекта;

var arrayLength = [].length;
var firstPosInString = "foo".indexOf("o");

... где как новые методы Object похожи;

var obj = { };
Object.defineProperty(obj, {
    value: 'a',
    writable: false
});

..когда следующее было бы гораздо более соответствующим:

var obj = { };
obj.defineProperty({
    value: 'a',
    writable: false
});

Может кто-нибудь охладить мое любопытство относительно того, почему это так?Есть ли фрагменты кода, которые это сломало бы?Есть ли какие-либо публичные дискуссии, сделанные комитетом по стандартам относительно того, почему они выбрали этот подход?

Answer 1

Все это очень хорошо объяснено в «Предложенном ECMAScript 3.1 Функции статических объектов: варианты использования и обоснование» (pdf) самого Аллена Вирфса-Брока (редактор спецификации ES5 и член TC39). ).

Я бы предложил прочитать все это. Она довольно короткая, легко усваивается и дает представление о мыслительном процессе этих дополнений ES5.

Но процитирую соответствующий раздел (выделение мое):

Ряд альтернативных конструкций API были рассмотрены до предложенный API был выбран. В процессе рассмотрения альтернатив мы разработал набор неофициальных руководящих принципов, которые мы применяли, когда рассматривая альтернативы. Эти рекомендации:

• Чисто разделение мета-слоя и прикладного слоя .
• Постарайтесь минимизировать площадь поверхности API (т. Е. Количество методов и сложность их аргументов).
• Сосредоточьтесь на удобстве использования в именовании и разработке параметров.
• Старайтесь многократно применять основные элементы конструкции.
• Если возможно, разрешите программистам или реализациям статически оптимизировать использование API.

[...]

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

Очевидная первоначальная идея, следуя примеру уже существующий стандартный метод Object.prototype.propertyIsEnumerable, должен был добавить дополнительные методы запроса «propertyIs ...» в Object.prototype для другие атрибуты и параллельный набор методов изменения атрибутов.

[...]

Когда мы рассматривали этот подход, в нем было много вещей что нам не понравилось, и это казалось противоречащим приведенному выше дизайну API рекомендации:

• Он объединяет, а не разделяет мета и прикладные слои . Как методы для Object.prototype, методы будут частью общедоступной интерфейс каждого объекта приложения в программе. Как таковые, они нуждаются быть понятным каждому разработчику, а не только разработчикам библиотеки.

[...]

Answer 2

API JavaScript всегда вращался вокруг работы с самим объектом;

Это не правильно. Например. JSON и Math всегда имели собственные методы. Никто не делает такие вещи:

var x = 0;
x.cos(); // 1.0
({"a":[0,1],"p":{"x":3,"y":4}}).toJSON();

В Интернете есть множество статей о том, почему расширение Object.prototype - это плохо. Да, речь идет о клиентском коде, но возможно это плохо для встроенных методов, а также для некоторых моментов.