From closures to prototypes, part 1
There are basically two ways to define classes in JavaScript: closures, where the constructor of the class both adds methods to the new instance and provides a common context for them, and prototypes, which are the first place JavaScript will look at when looking for a member that isn't directly defined on the instance. Don't worry if you don't understand everything I just said, I'll show and explain.
Closures are functions that are defined in a context. This context is the sum of all the objects that are defined at the scope where the function is defined. The catch is that the function not only can access this context, it will also take it with itself everywhere it goes. In other words, closures are functions that remember where they came from. In JavaScript, functions automatically get that quality. Here's an example:
function createClosure(a) { var b = 42; return function(c) { return "a=" + a + ", b=" + b + ", c=" + c; } } var closure1 = createClosure(1); alert(closure1(8)); // a=1, b=42, c=8 alert(closure1(9)); // a=1, b=42, c=9 var closure2 = createClosure(2); alert(closure2(10)); // a=2, b=42, c=10Coupled with the semantics of the this pointer, closures enable the construction of class instances that have real private variables:
function Point(x, y) { var _x = x; var _y = y; this.get_x() { return _x; } this.get_y() { return _y; } }
In this example, we have constructed a truly immutable Point structure. There is no way to modify the private members _x and _y, and you can only get their values through the accessors. It's nice to have truly private members and it's actually useful to build security in mashup scenarios where pieces of code come from untrusted sources. It's extremely tricky to get right but it can be done.
Now in most other situations, it's not really of paramount importance that your private variables remain untouchable. Actually, in .NET, private members are accessible through reflection. You need reflection permissions, but they sure are accessible. Furthermore, there is one circumstance where you do want your private variables very accessible, and that is when debugging. Inspecting private fields is one of the main things you want to be able to do from a debugger, especially when property accessors are not being automatically evaluated by the tool.
So even if it seemed like a good idea to get really private variables, well it really isn't (except when you really, really need them).
But there's another problem with closure-based classes and that's performance. For every instance you create, all the methods have to be recreated. This means that you pay a higher price to object creation and that the working set gets bigger with each instance.
Let's look at prototype-based classes and see the pros and cons of that approach. Here's the same point structure built using prototypes:
function Point(x, y) { this._x = x; this._y = y; } Point.prototype.get_x = function() { return this._x; } Point.prototype.get_y = function() { return this._y; }
In this case, _x and _y are only private by convention. Nothing prevents anyone from tampering with them. In most cases though, that's fine, and you actually want that to be possible from the debugger.
Performance-wise, prototypes are also better in almost every situation. First, they minimize the working set: here, there's only one copy of the get_x and get_y functions for all Point instances. What differentiates the instances is only what this points to. In terms of speed, creating instances is faster, but calling methods is just a little slower because of the need to lookup the method on the prototype chain.
So far, Atlas has been using closures. Starting with the next version, all of our classes will be using prototypes. Closures are still supported but prototypes are the recommended pattern.
In part 2, I'll show how to easily transition a closure-based Atlas class library to prototypes, with clear do's and don't's.
Read on: http://weblogs.asp.net/bleroy/archive/2006/10/14/From-closures-to-prototypes_2C00_-part-2.aspx