Ответ 1
Все это объясняется очень хорошо в "Предлагаемый ECMAScript 3.1 Статические функции объекта: использование случаев и обоснование" документ (pdf) самим Алленом Вирфсом-Броком (редактор ES5, и членом TC39).
Я бы предложил прочитать все это. Он довольно короткий, легко удобоваримый, и дает хороший проблеск мыслительного процесса за этими дополнениями ES5.
Но процитировать соответствующий раздел (внимание мое):
Несколько альтернативных проектов API были рассмотрены до предложенный API. В ходе рассмотрения альтернатив мы разработал ряд неофициальных руководящих принципов, которые мы применяли, когда учитывая альтернативы. Эти рекомендации:
- Чисто отделить уровни мета и приложений.
- Попробуйте минимизировать площадь поверхности API (т.е. количество методов и сложность их аргументов).
- Сосредоточьтесь на удобстве использования именования и дизайна параметров.
- Попробуйте повторно применить основные элементы дизайна.
- Если возможно, разрешите программистам или реализациям статически оптимизировать использование API.
[...]
Вот некоторые из рассмотренных альтернатив, которые приводят к выбранный дизайн.
Очевидная первоначальная идея, следуя примеру уже существующий стандартный метод Object.prototype.propertyIsEnumerable, должен был добавьте дополнительные методы запроса "propertyIs..." в Object.prototype для другие атрибуты и параллельный набор методов изменения атрибутов.
[...]
Как мы рассматривали этот подход, об этом было много чего что нам не понравилось, и это казалось противоречивым описанному выше дизайну API рекомендации:
- Он объединяется, а не разделяет уровни мета и приложений. Как методы Object.prototype методы будут частью публичной интерфейс каждого объекта приложения в программе. Как таковые, им нужно чтобы их понимали все разработчики, а не только дизайнеры библиотек.
[...]