ES5 added a number of methods to Object, which seem to break the semantic consistency of JavaScript.

For instance, prior to this extension, the JavaScript API always revolved around operarting on the object itself;

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

... where as the new Object methods are like;

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

... when the following would have been much more conformative:

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

Can anyone cool my curiosity as to why this is? Is there any code snippets that this would break? Are there any public discussions made by the standards mittee as to why they chose this approach?

ES5 added a number of methods to Object, which seem to break the semantic consistency of JavaScript.

For instance, prior to this extension, the JavaScript API always revolved around operarting on the object itself;

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

... where as the new Object methods are like;

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

... when the following would have been much more conformative:

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

Can anyone cool my curiosity as to why this is? Is there any code snippets that this would break? Are there any public discussions made by the standards mittee as to why they chose this approach?

• javascript
• ecmascript-5
• consistency

2 Answers 2

This is all explained very nicely in "Proposed ECMAScript 3.1 Static Object Functions: Use Cases and Rationale" document (pdf) by Allen Wirfs-Brock himself (editor of ES5 spec, and a member of TC39).

I would suggest to read all of it. It's pretty short, easily digestible, and gives a nice glimpse of the thought process behind these ES5 additions.

But to quote relevant section (emphasis mine):

A number of alternatives API designs were considered before the proposed API was chosen. In the course of considering alternatives we developed a set of informal guidelines that we applied when considering the alternatives. These guidelines are:

• Cleanly separate the meta and application layers.
• Try to minimize the API surface area (i.e., the number of methods and the plexity of their arguments).
• Focus on usability in naming and parameter design.
• Try to repeatedly apply basic elements of a design.
• If possible, enable programmers or implementations to statically optimize uses of the API.

[...]

Here are some of the alternatives that were considered that lead to the selected design.

The obvious initial idea, following the example of the already existing standard method Object.prototype.propertyIsEnumerable, was to add additional “propertyIs...” query methods on Object.prototype for the other attributes and a parallel set of attribute changing methods.

[...]

As we considered this approach there were a number of things about it that we didn’t like and that seemed contrary to the above API design guidelines:

• It merges rather than separates the meta and application layers. As methods on Object.prototype the methods would be part of the public interface of every application object in a program. As such, they need to be understood by every developer, not just library designers.

[...]

the JavaScript API always revolved around operarting on the object itself;

This is not correct. E.g. JSON and Math always had own methods. Nobody does such things:

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

There are numerous articles on the web about why extending Object.prototype is a bad thing. Yes, they're about client code, but maybe this is bad for build-in methods also for some points.