views:

449

answers:

3

ECMAScript 5 has quite a few nice additions. John Resig has a good overview here. Here is a good ECMAScript 5 compatibility table.

A lot of this stuff can be "faked" for browsers that don't support these functions yet. Do you know of any scripts that can do this? I'm particularly interested in Object.create.

For example, Douglas Crockford's JSON script checks if JSON functions exist before creating them.

If there was more like the JSON one we could include them when we need to use the new functions.

+2  A: 

es5 - JavaScript/EcmaScript 5 in 3 is a collection shared at BitBucket. Object.create in particular is an easy one to fake, made popular by Crockford et al, but improved on here by Justin Love, focussing on many ES5 parts.

Dean Burge
+17  A: 

Crockford recommends this kind of Object.create shim:

if (typeof Object.create != "function") {
  Object.create = function (o) {
    function F(){}
    F.prototype = o;
    return new F;
  };
}

But please don't do this.

The problem with this approach is that ES5 Object.create has a signature of 2 arguments: first — an object to inherit from, and second (optional) — an object representing properties (or rather, descriptors) to add to newly created object.

Object.create(O[, Properties]); // see 15.2.3.5, ECMA-262 5th ed.

What we have is an inconsistent implementation with 2 different behaviors. In environments with native Object.create, method knows how to handle second argument; in environments without native Object.create, it doesn't.

What are the practical implications?

Well, if there's some code (say, a third party script) that wants to use Object.create, it's rather reasonable for that code to do this:

if (Object.create) {
  var child = Object.create(parent, properties);
}

— essentially assuming that if Object.create exists, it must conform to specs — accept second argument and add corresponding properties to an object.

But, with the above-mentioned shim, second argument is simply ignored. There's not even an indication of something going wrong differently. A silent failure, so to speak — something that's rather painful to detect and fix.

Can we do better? Yes. There are few solutions:

1) Notify user about inability to work with second argument

if (!Object.create) {
  Object.create = function (o) {
    if (arguments.length > 1) { 
      throw Error('second argument is not supported'); 
    }
    // ... proceed ...
  };
}

2) Try to handle second argument:

if (!Object.create) {
  Object.create = function (parent, properties) {
    function F(){}
    F.prototype = parent;
    var obj = new F;
    if (properties) {
      // ... augment obj ...
    }
    return obj;
  }; 
}

Note that "properties" is an object representing property descriptors, not just property names/values, and is something that's not very trivial to support (some things are not even possible, such as controlling enumerability of a property):

Object.create(parent, {
  foo: {
    value: 'bar',
    writable: true
  },
  baz: {
    get: function(){ return 'baz getter'; },
    set: function(value){ return 'baz setter'; },
    enumerable: true
  }
});

Oh, and I almost forgot about another inconsistency where original shim doesn't take care of parent object being null.

var foo = Object.create(null);

This creates an object whose [[Prototype]] is null; in other words, object that doesn't inherit from anything, not even Object.prototype (which all native objects in ECMAScript inherit from).

foo.toString; // undefined
foo.constructor; // undefined
// etc.

This is, by the way, useful to create "proper" hash tables in ECMAScript.

It's possible to emulate this behavior, but only using non-standard extensions, such as "magical" __proto__ property (so implementation would be not very portable or robust). Solution to this problem is similar: either emulate ES5 implementation fully, or notify about inconsistency/failure.

kangax
My [Xccessors JavaScript library](http://github.com/eligrey/Xccessors) provides `Object.defineProperty` and `Object.defineProperties` functions that you can use for solution #2.
Eli Grey
That's very well spotted and your knowledge of ES5 is obviously solid but I think it's worth pointing out that Crockford's code predates ES5 by quite a while: first version circa 2006 and the latest, early 2008. So it's a little bit disingenuous to suggest that he 'recommends' this solution to shim over ES5.
neonski
Last time I've seen Doug talk about this shim was 3 months ago — http://www.slideshare.net/douglascrockford/javascript-the-good-parts-3292746/36 That's about 4 months after ES5 was officially standardized (in Dec 09) and is definitely later than 2008.But I don't want to blame anyone (sorry if it came out that way). We all make mistakes. The idea is to recommend against **the approach** and explain why.
kangax
So do you recommend the solutions you mention here, or something else altogether?
Bob Spryn
@Bob Spryn, solutions #1 or #2 are both better than original one. You could also use different name for a method (e.g. `SomeLibrary.object.create`); as long as there's no inconsistent behavior across different environments.
kangax
@kangax Thanks!
Bob Spryn
+1  A: 

es5-shim http://github.com/kriskowal/es5-shim/

This was part of the narwhal stand-alone javascript environment, but has been broken out on its own. It's pretty darn mature and precise.

Sean McMillan