The gripe of the day is how JS makes reflection part of the everyday programming flow. And it is not reliable reflection, it is crippled reflection with lots of gotchas. I’ll focus on two reflection mechanisms in JS today, for-in loops and square bracket annotations (member lookup expression, array['length']). The foor-in loop is used to loop over the properties of an object. But it only includes enumerable properties. Also, it incudes the enumerable properties of the objects prototype. The member lookup expression is used to lookup a property based on its name, which is always a string.

The problem is that people tend to use this reflective mechanism to do Map data structures. It is not surprising since there is no Map data structure in JS (before ES6) and the syntax is very convenient. Of course you want to write what you mean; map[key] = value instead of map.set(key, value).

Lets go on. What if I want to add a size getter on my map that returns the number of entries in the map? Now I can no longer add an entry with the key "size" since that would replace or shadow the size getter. This is a real problem and a lot of web site crash if you enter the string "__proto__" or the string "hasOwnProperty. For example Google Docs used to crash if you entered the former of those two.

What if I wanted to have non string keys? Nope, only strings are allowed and the key will be the toString() string of the key object. The common solution to this is to build a Map data structure where the key is a unique ID (UID) and the UID gets added to the real key object. This of course breaks if the key is a non extensible objects and those of you who have been around for a long time might remember that Nodes coming from an XHR in IE where non extensible causing all kinds of head aches.

The Future

ES6 has a new kind of loop called for-of. The for of loop is not a reflective loop. It is an iteration loop. The object that you want to iterate over must have an iterator and by default Object.prototype does not. Array.prototype on the other hand has an iterator that iterates over the elements in the array. Just what you always wanted!

for (let value of [0, 'one', true]) {
  console.log(value);
}

for (let value of {a: 1}) {  // throws not iterable
  console.log(value);
}

ES6 has Map and Set which allows any value as a key. This solves some of the issues but we still have the mess with the member lookup expression.

There is a proposal on the ES wiki that tries to reform the object model and decouple [] from property lookup. The basic idea is that any object can override the [] operations. Existing objects would continue to work as they do today but new objects could opt in to this new behavior.

For example, we could extend the ES6 Map objects to allow [] and []= like this:

import {elementGet, elementSet} from '@name';
Map.prototype[elementSet] = function(key, value) {
  return this.set(key, value);
};
Map.prototype[elementGet] = function(key) {
  return this.get(key);
};

var m = new Map;
var key = {};
m[key] = 42;
console.log(m[key]);

The reformed object model also allows us to finally explain how arrays work. It also allows us to implement all of the DOM interfaces in pure JavaScript. For example we could implement NodeList like this:

import {create, elementGet} from '@name';
const ownerName = create();
const lengthName = create();

export function NodeList(owner) {
  this[ownerName] = owner;
}

NodeList.prototype  = {
  get length() {
    let i = 0;
    for (let node = this[ownerName].firstChild; node; node = node.nextSibling) {
      i++;
    }
    return i;
  },

  [elementGet]: function(index) {
    let i = 0;
    for (let node = this[ownerName].firstChild; node; node = node.nextSibling) {
      if (i++ === index)
        return node;
    }
    return node;
  }
};

Today

Map and Set are implemented in SpiderMonkey and V8 and is available under a flag in Chrome and in Firefox without a flag.

For-of loops are available in Firefox. V8 hasn’t started working on for-of loops nor iterators so don’t expect to be able to use these without a transpiler any time soon.

Both for-of loops and the reformed object model are available in the Traceur compiler. There is a naïve demo of a string keyed map too. Note that [] keys are not yet supported in object/class literals so the demo uses assignment instead.

Proxies are a very low lever construct. The are very powerful and they allow an object to intercept any access to its properties as well as intercept things like [[Call]] and [[Construct]]. There are some limitations though; the [[Prototype]] cannot change once created and there is currently no way to intercept internal properties such as [[Class]].

The basic idea is that you create a new object (the proxy) that has a handler. The handler has a bunch of functions that will get called when different operations are done to the proxy object. For example when someone sets a property the set set trap of the proxy is called.

var handler = {
  set: function(receiver, name, value) {
    console.log(name, 'was set to', value, 'on', receiver);
  }
};
var proxy = Proxy.create(handler, {});
proxy.meaning = 42;  // Logs 'meaning' was set to 42 on [Object object]

Proxies are useful to emulate DOM as well as for doing membranes etc. I don’t expect anyone but library authors to ever have to use them directly.

typeof null  // 'null'

In V8 with the Harmony flag turned on this changes all the typeof expressions so beware and please update your JS libraries to be future compatible to handle this correctly. Something along the following lines should make your code work both in ES5 and in future versions of ES:

switch (typeof expression) {
  case 'boolean':
    ...
    break;
  case 'function':
    ...
    break;
  case 'number':
    ...
    break;
  case 'string':
    ...
    break;
  case 'undefined':
    ...
    break;
  default:  // object or null
    var isNull = expression === null;
    ...
}

// Bad, because it included null in old ES versions
typeof object === 'object'

// Good
object === null

function f() { console.log('outer'); }

{
  function f() { console.log('inner'); }
  f();  // logs 'inner'
}
f();  // logs 'outer'

The block scoped bindings proposal also covers let and const. The let binding is like a var except that its scope is limited to the current block. const is like let but it requires an initializer and can only be written to once.

var functions = [];
for (var i = 0; i < 5; i++) {
  var x = i;
  functions.push(function() {
    alert(x);
  });
}
functions[0]();

The code above alerts 5 because that is what x is when the function is called. Now lets change the inner var to a let.

var functions = [];
for (var i = 0; i < 5; i++) {
  let x = i;
  functions.push(function() {
    alert(x);
  });
}
functions[0]();

This now alerts 0 since every iteration gets a fresh local variable.

const PI = 3.14159265;
// ...
PI = 'Apple Pie';  // throws because PI cannot be reassigned to.

To use these you currently need to use strict mode.

'use strict';
// ...

// or
function f() {
  'use strict';
  // ...
}

var map = new Map;
map.set('a', 'A');
map.get('a');  // 'A'
var b = {};
map.set(b, 'B');
map.get(b);  // 'B'
map.has(b);  // true

var set = new Set;
set.add('a');
set.has('a');  // true
var b = {};
set.add(b);
set.has(b);  // true

Harmony also provides another kind of map called WeakMap. This has the same API as Map but it has different GC semantics. A normal Map using an object as a key prevents the object from being garbage collected but with a WeakMap the object can be garbaged collected. This is useful when you associate data with someone else’s object.

var map = new WeakMap;
map.set(elementA, 'A');
map.get(elementA);  // 'A'
map.set(elementB, 'B');
map.get(elementB);  // 'B'
map.has(elementB);  // true

In the above example, if the element is removed from the DOM and the script has no references to it the element can be garbage collected.

Unlike Map and Set, WeakMap will never have a way to iterate over the items since that would expose the GC behavior.

The following 4 features are currently enabled if you turn on the experiment.

• Collections (Map, Set, WeakMap)
• Block scoped bindings
• typeof null === 'null'
• Proxies

Over the next couple days I’ll post individual posts about each of these.

When I attended The Ajax Experience 2009, I saw a number of “misguided” things that people were doing with JavaScript. [snip].. I wanted to get up and yell, “Stop — you’re all doing it wrong!”

Although I agree with almost everything Michael writes I think it is worth pointing out some things.

Background

For those too lazy to read Michael’s post and article here is an example of the classic inheritance pattern as well as the functional inheritance pattern. This example is intentionally very simple.

Classic inheritance pattern

function Phone(phoneNumber) {
  this.phoneNumber_ = phoneNumber;
};

Phone.prototype.getPhoneNumber = function() {
  return this.phoneNumber_;
};

Functional inheritance pattern

function Phone(phoneNumber) {
  var that = {};
  that.getPhoneNumber = function() {
    return phoneNumber;
  };
  return that;
};

Compilation

Michael argues that the functional pattern is not good because methods cannot be inlined and the end result is much larger. He also says that it uses more memory. I think it is important to realize that it uses a LOT more memory and is significantly slower. Given a class with 1 methods It is about 100 times slower in Chrome, 20 times slower in Safari and about 10 times slower in Firefox.

Prototype object literal

Michael also mentions the following pattern:

function Phone(phoneNumber) {
  this.phoneNumber_ = phoneNumber;
}
Phone.prototype = {
  getPhoneNumber: function() {
    return this.phoneNumber_;
  }
};

I like this pattern but it has one serious drawback. It cannot be used to extend existing classes because in that case the protytype must be an instance of the class you are inheriting from.

If you do not care about IE support this can be done by using __proto__ like this:

function SmartPhone(phoneNumber) {
  Phone.call(this, phoneNumber);
}
SmartPhone.prototype = {
  __proto__: Phone.prototype,
  sendEmail: function(email) {
    ...
  }
};

Semantics

I understand why people like Douglas Crockford preaches the functional inheritance pattern. Due to its closure the local variable is truly private and this is important when you are doing mashups and other security sensitive code. However, when it comes to building large scale applications like Gmail you cannot afford this extra memory and performance overhead.

Conclusion

Prototype based inheritance is the way to go if you care about memory usage and performance. If you are planning to use the Closure Compiler you will also see greater code size reduction using this pattern.

Update

As some people pointed out method dispatch is slightly slower using the classic inheritance pattern because we have to walk the prototype chain to find the method. I’m also posting my tests and results for reference:

• Create test
• Method dispatch test
• Table of results

You might need to reduce the number of runs to get this to wrok in IE. The only surprising thing here is that the classical pattern is faster in Firefox nightlies.

Yesterday morning (when reading a lengthy email to es-discuss) I realized that I could probably use catch-alls to emulate super. Catch-alls is a SpiderMonkey feature that allows an object to have a method that will be called when a non existing method is called. Catch-alls are proposed for ES-Harmony. The idea I had was to create a super object that uses the catch-all mechanism to call the method on the super class with this bound to the current object. I wanted to achieve something like this:

function B() {
  supr(1, 2, 3);
  this.method = function(x) {
    supr.method(x);
    ...
  };
}
inherits(B, A);

Instead of having to write:

function B() {
  A.call(this, 1, 2, 3);
  this.method = function(x) {
    A.prototype.method.call(this, x);
    ...
  };
}
inherits(B, A);

So supr needs to be a function which has the __noSuchMethod__ method set to call the method of the [[Prototype]] object.

Take one:

function B() {
  var self = this;
  var supr = function() {
    return A.apply(self, arguments);
  };
  supr.__noSuchMehod__ = function(name, args) {
    return A.prototype[name].apply(self, args);
  };

  supr(1, 2, 3);
  this.method = function(x) {
    supr.method(x);
    ...
  };
}
inherits(B, A);

Lets take a look at the inherits function. It is something all js dev heads should have in their repertoire. It is extremely useful and it allows you to declare inheritance without having to create an instance of the super class.

function inherits(child, parent) {
  var f = function() {};
  f.prototype = parent.prototype;
  child.prototype = new f;
  child.prototype.constructor = child;
  child.superClass = parent;
}

The last two lines are important because JS does not maintain the mapping to the constructor and by adding the superClass property it allows us to easily get access to the parent constructor.

With the innards of the inherits function known combined with take one above we can write a helper function that makes creating the supr object a lot easier.

function createSuper(self, opt_constr) {
  var constr = opt_constr || arguments.callee.caller;
  function supr() {
    return constr.superClass.apply(self, arguments);
  };
  supr.__noSuchMethod__ = function(name, args) {
    if (typeof constr.superClass.prototype[name] == 'function') {
      return constr.superClass.prototype[name].apply(self, args);
    }
    throw Error('No such method, ' + name);
  };
  return supr;
}

And then we can use this.

function A(x) {
  print('In A constructor, x = ' + x);
}
A.prototype.a = function(x) {
  print('In A.prototype.a, x = ' + x);
};


function B(x) {
  print('In B constructor');
  var supr = createSuper(this);

  supr(x || 'From B');
  var className = 'B';
  this.a = function(x) {
    print('In ' + className + '.a');
    supr.a(1);
  };
}
inherits(B, A);


function C(x) {
  print('In C constructor');
  var supr = createSuper(this);

  supr(x || 'From C');
}
inherits(C, B);
C.prototype.a = function() {
  var supr = createSuper(this, C);
  print('In ' + 'C' + '.a');
  supr.a('supr.a called from a c object');
};


print('Creating an instance of B');
b = new B;
b.a(2);

print('');
print('Creating an instance of C');
c = new C;
c.a();

Try this (Firefox only)

This works because supr is recreated for every constructor and is bound lexically Don’t do this.supr = supr and think you can reuse it. It will not work. This does not require that you put the methods that needs super inside the constructor but if you don’t you will have to call createSuper and pass in your constructor from your method which is not very efficient and it is hardly much better than using the straight forward way to call super by just getting the function of the super class prototype and call it by name (A.prototype.a.call(this, 1)).

Conclusion

Once again I find that adding code to make things simpler in JS is unsuccessful. The costs for adding better ways to do things don’t pay for itself. (Except for the inherits function of course.)