Why were ES5 Object methods not added to Object.prototype?

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 complexity 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.

[…]

Leave a Comment