¿Por qué los métodos de objeto ES5 no se agregaron a Object.prototype?

Question

ES5 agregó un number de methods a Object, que parecen romper la consistencia semántica de JavaScript.

Por ejemplo, antes de esta extensión, la API de JavaScript siempre giraba en torno al operarting en el objeto en sí;

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

... donde como son los nuevos métodos de Objeto;

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

... cuando el siguiente habría sido mucho más conformante:

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

Puede alguien me refresque la curiosidad de por qué es esto? ¿Hay algún fragmento de código que rompa? ¿Hay algún debate público realizado por el comité de normas sobre por qué eligieron este enfoque?

Answer 1

Todo esto se explica muy bien en "Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale" document (pdf) por el propio Allen Wirfs-Brock (editor de la especificación ES5 y miembro de TC39).

Le sugiero leerlo todo. Es bastante corto, de fácil digestión y da una buena idea del proceso de pensamiento detrás de estas adiciones de ES5.

Pero para citar sección correspondiente (el énfasis es mío):

se consideraron una serie de alternativas de diseños API antes de elegir el API propuesto. En el curso de considerar alternativas, desarrollamos un conjunto de pautas informales que aplicamos cuando considerando las alternativas. Estas directrices son:

• limpiamente separar las capas meta y aplicación.
• Intente minimizar el área de superficie de API (es decir, el número de métodos y la complejidad de sus argumentos).
• Enfoque en la usabilidad en el nombramiento y diseño de parámetros.
• Intente aplicar elementos básicos de un diseño repetidamente.
• Si es posible, habilite programadores o implementaciones para optimizar de manera estática los usos de la API.

[...]

Estas son algunas de las alternativas que se consideraron que conducen a el diseño seleccionado.

La idea inicial obvia, siguiendo el ejemplo del método estándar ya existente Object.prototype.propertyIsEnumerable, era añadir “...” propertyIs adicionales sobre métodos de consulta para Object.prototype los otros atributos y un paralelo conjunto de métodos de cambio de atributos.

[...]

Como hemos considerado este enfoque había un número de cosas sobre él que no nos gusta y que parecían contrarias al diseño API por encima de directrices:

• Es combina en lugar de separa las capas de meta y aplicación. Como métodos en Object.prototype, los métodos serían parte de la interfaz pública de cada objeto de aplicación en un programa. Como tales, necesitan para que los entiendan todos los desarrolladores, no solo los diseñadores de bibliotecas.

[...]

Answer 2

la API de JavaScript siempre giró en torno al funcionamiento en el objeto mismo;

Esto no es correcto. P.ej. JSON y Math siempre tenían métodos propios. Nadie hace este tipo de cosas:

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

Hay numerosos artículos en la web acerca de por qué se extiende Object.prototype es una mala cosa. Sí, están sobre cliente código, pero quizás esto es malo para los métodos de construcción también para algunos puntos.