views:

389

answers:

3

There are only 3 lines of code, and yet I'm having trouble fully grasping this:

Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
};
newObject = Object.create(oldObject);

(from Prototypal Inheritance)

1) Object.create() starts out by creating an empty function called F. I'm thinking that a function is a kind of object. Where is this F object being stored? Globally I guess.

2) Next our oldObject, passed in as o, becomes the prototype of function F. Function (i.e., object) F now "inherits" from our oldObject, in the sense that name resolution will route through it. Good, but I'm curious what the default prototype is for an object, Object? Is that also true for a function-object?

3) Finally, F is instantiated and returned, becoming our newObject. Is the "new" operation strictly necessary here? Doesn't F already provide what we need, or is there a critical difference between function-objects and non-function-objects? Clearly it won't be possible to have a constructor function using this technique.

What happens the next time Object.create() is called? Is global function F overwritten? Surely it is not reused, because that would alter previously configured objects. And what happens if multiple threads call Object.create(), is there any sort of synchronization to prevent race conditions on F?

+2  A: 

Your major misunderstanding here is that F has global scope. It is declared in the body of Object.create and consequently is only in scope within that method block.

spender
and, to the amazement of C++ guys, it's not destroyed at block exit. (hint, the created object keeps a reference, so the GC doesn't kill it even if it's not directly accessible)
Javier
+5  A: 

1) A function is indeed a kind of object. A function object with identifier F is created each time Object.create is called, and is only accessible with that identifier within that execution of Object.create. Therefore, each time Object.create is called, you get a different function object F. This function object lives on as the constructor property of the object returned by Object.create.

2)

F now "inherits" from our oldObject, in the sense that name resolution will route through it

This isn't really correct. Assigning an object someObject to the prototype property of a function just means that the prototype of any future object created by calling this function as a constructor will be someObject.

3) The new is absolutely vital to this technique. Only by calling a function as a constructor does it produce a new object, and that object's prototype (which is not generally accessible) is set to the constructor function's prototype property. There is no other (standardised) way to set an object's prototype.

Finally, JavaScript in browsers is single threaded, so race conditions such as you describe are not possible.

Tim Down
Race conditions wouldn't apply anyway, since `F` is local to the `Object.create` function, not global.
Matthew Crumley
Matthew: very true, thanks.
Tim Down
+6  A: 

1) Object.create() starts out by creating an empty function called F. I'm thinking that a function is a kind of object. Where is this F object being stored? Globally I guess.

No, it's stored on the local scope of the Object.create function, each time you invoke Object.create this function F will be recreated.

You could even create a more memory-efficient implementation, by storing F on a closure, and reuse it:

if (typeof Object.create !== "function") {
  Object.create = (function () {
    function F() {} // created only once
    return function (o) {
      F.prototype = o; // reused on each invocation
      return new F();
    };
  })();
}

2) Next our oldObject, passed in as o, becomes the prototype of function F. Function (i.e., object) F now "inherits" from our oldObject, in the sense that name resolution will route through it. Good, but I'm curious what the default prototype is for an object, Object? Is that also true for a function-object?

All objects have an internal property that builds the prototype chain, this property is known as [[Prototype]], it's an internal property, although some implementations let you access to it, like mozilla, with the obj.__proto__ property.

The default [[Prototype]] when you create a new object, i.e. var obj = {}; is Object.prototype.

All functions have a prototype property, this property is used when a function is used as a Constructor, invoked with the new operator.

A new object instance it's created behind the scenes, and this object [[Prototype]] is set to its Constructor's prototype property.

3) Finally, F is instantiated and returned, becoming our newObject. Is the "new" operation strictly necessary here? Doesn't F already provide what we need, or is there a critical difference between function-objects and non-function-objects? Clearly it won't be possible to have a constructor function using this technique.

Yes, the new operator is essential in this method.

The new operator is the only standard way to set the [[Prototype]] internal property of an object, if you are curious about how it works, you can give a look to the [[Construct]] internal operation.

What happens the next time Object.create() is called? Is global function F overwritten? Surely it is not reused, because that would alter previously configured objects. And what happens if multiple threads call Object.create(), is there any sort of synchronization to prevent race conditions on F?

The next time Object.create is invoked, a new local F function is instantiated only within the scope of the method call, you shouldn't worry about race conditions.

Note that this implementation hardly conforms the Object.create described in the ECMAScript 5th Edition Specification, in that method, you could pass a property descriptor to initialize the object.

All browser vendors are implementing it (already available on Firefox 3.7 alphas, latest Wekit Nightly Builds and Chrome 5 Beta), so I would recommend you at least to check if a native implementation exist before overriding it.

CMS
Hmm, no race condition for Crockford due to local scope, but what about your reuse version?
Chris Noe
@Chris, no race condition also, the nature of JavaScript is single threaded, even [timers and other asynchronous events](http://ejohn.org/blog/how-javascript-timers-work/) like user interaction are executed sequentially in a blocking single thread.
CMS
Thanks for the excellent point-by-point!
Chris Noe
Conversations like these will keep me from being too cavalier about threading assumptions: http://stackoverflow.com/questions/2734025/is-javascript-guaranteed-to-be-single-threaded, http://www.oreillynet.com/cs/user/view/cs_msg/81559
Chris Noe