Question

Suppose I have an object foo in my JavaScript code. foo is a complex object and it is generated somewhere else. How can I change the prototype of the foo object?

My motivation is setting appropriate prototypes to objects serialized from .NET to JavaScript literals.

Suppose that I’ve written the following JavaScript code within an ASP.NET page.

var foo = <%=MyData %>;

Suppose that MyData is the result of invoking the .NET JavaScriptSerializer on a Dictionary<string,string> object.

At run-time, this becomes the following:

var foo = [{"A":"1","B":"2"},{"X":"7","Y":"8"}];

As you can see, foo becomes an array of objects. I would like to be able to initialize foo with an appropriate prototype. I do not want to modify the Object.prototype nor Array.prototype. How can I do this?

Answer 1

Update: ES6 now specifies Object.setPrototypeOf(object, prototype)

How you use this depends on what "the new prototype" is based. Given some object obj:

1. if the new prototype is a plain object something, use Object.setPrototypeOf(obj, something),
2. if the new prototype is based on an ES5-and-below-style constructor function function Something() {...} with its own corresponding Something.prototype = {...}, use Object.setPrototypeOf(obj, Something.prototype),
3. and if the new prototype is an ES6 class class Something { ... }, use Object.setPrototypeOf(obj, Something.prototype).

EDIT Feb. 2012: the answer below is no longer accurate.

__proto__ is being added to ECMAScript 6 as "normative optional" which means it isn’t required to be implemented but if it is, it must follow the given set of rules. This is currently unresolved but at least it will be officially part of JavaScript’s specification.

This question is a lot more complicated than it seems on the surface, and beyond most peoples’ pay grade in regards to knowledge of Javascript internals.

The prototype property of an object is used when creating new child objects of that object. Changing it does not reflect in the object itself, rather is reflected when that object is used as a constructor for other objects, and has no use in changing the prototype of an existing object.

function myFactory(){};
myFactory.prototype = someOtherObject;

var newChild = new myFactory;
newChild.__proto__ === myFactory.prototype === someOtherObject; //true

Objects have an internal [[prototype]] property which points to the current prototype. The way it works is whenever a property on an object is called it will start at the object and then go up through the [[prototype]] chain until it finds a match, or fail, after the root Object prototype. This is how Javascript allows for runtime building and modification of objects; it has a plan for searching for what it needs.

The __proto__ property exists in some implementations (a lot now): any Mozilla implementation, all the webkit ones I know of, some others. This property points to the internal [[prototype]] property and allows modification post-creation on objects. Any properties and functions will instantly switch to match the prototype due to this chained lookup.

This feature, while being standardized now, still is not a required part of JavaScript, and in languages supporting it has a high likelihood of knocking your code down into the "unoptimized" category. JS engines have to do their best to classify code, especially "hot" code which is accessed very often, and if you’re doing something fancy like modifying __proto__, they won’t optimize your code at all.

This posts https://bugzilla.mozilla.org/show_bug.cgi?id=607863 specifically discusses current implementations of __proto__ and the differences between them. Every implementation does it differently, because it’s a hard and unsolved problem. Everything in Javascript is mutable, except a.) the syntax b.) host objects (the DOM exists outside Javascript technically) and c.) __proto__. The rest is completely in the hands of you and every other developer, so you can see why __proto__ sticks out like a sore thumb.

There is one thing that __proto__ allows for that is otherwise impossible to do: the designation of an objects prototype at runtime separate from its constructor. This is an important use case and is one of the primary reasons __proto__ isn’t already dead. It’s important enough that it’s been a serious discussion point in the formulation of Harmony, or soon to be known as ECMAScript 6. The ability to specify the prototype of an object during creation will be a part of the next version of Javascript and this will be the bell indicating __proto__‘s days are formally numbered.

In the short term, you can use __proto__ if you’re targeting browsers that support it (not IE, and no IE ever will). It’s likely it’ll work in webkit and moz for the next 10 years as ES6 won’t be finalized until 2013.

Brendan Eich – re:Approach of new Object methods in ES5:

Sorry, … but settable __proto__, apart from the object initialiser use case (i.e., on a new object not yet reachable, analogous to ES5’s Object.create), is a terrible idea. I write this having designed and implemented settable __proto__ over 12 years ago.

… the lack of stratification is a problem (consider JSON data with a key "__proto__"). And worse, the mutability means implementations must check for cyclic prototype chains in order to avoid ilooping. [constant checks for infinite recursion are required]

Finally, mutating __proto__ on an existing object may break non-generic methods in the new prototype object, which cannot possibly work on the receiver (direct) object whose __proto__ is being set. This is simply bad practice, a form of intentional type confusion, in general.