Question

I’m currently writing objects in javascript and I would like to do it in a clear, nice way, using best practices etc. But I’m bothered that I must always write this. to address attributes, unlike in other OO languages.

So I got the idea – why not just use closures for object attributes? Look at my example object. So instead of this, classical way:

var MyObjConstructor = function (a, b) {

    // constructor - initialization of object attributes
    this.a = a;
    this.b = b;
    this.var1 = 0;
    this.var2 = "hello";
    this.var3 = [1, 2, 3];

    // methods
    this.method1 = function () {
        return this.var3[this.var1] + this.var2; 
            // terrible - I must always write "this." ...
    };

}

… I would do it using closure and then I don’t need to write this. every time to access the attributes!

var MyObjConstructor = function (a, b) {

    // constructor - initialization of object attributes
    // the attributes are in the closure!!!
    var a = a;
    var b = b;
    var var1 = 0;
    var var2 = "hello";
    var var3 = [1, 2, 3];

    // methods
    this.method1 = function () {
        return var3[var1] + var2;
            // nice and short
    };

    // I can also have "get" and "set" methods:
    this.getVar1 = function () { return var1; }
    this.setVar1 = function (value) { var1 = value; }
}

Also, it has a hidden benefit that the attributes really cannot be accessed any other way than by get/set methods!!

So the question is:

1. Is this a good idea? Is it “clean”, is it conforming to best practice?
2. Are there any other semantical differences between these 2 solutions?
3. Are there any traps with using closure like this?

Answer 1

To answer your questions directly:

1. Is it OK to use objects as closures? Is it conforming to best practices?

Yes. In some situations you really want to have private fields so this is the only way one the ways to do that. For a real, concrete, example have a look at Deferreds/Promises in Dojo or JQuery. The Promises implement just the non-mutating subset of deferreds so they need to keep their inner Deferred private to avoid others from changing it directly.

Do remember that you should only really use hidden fields where you really need them (and not for trivial reasons like not having to type “this”). Using plain old public fields and “normal” objects is also perfectly fine, especially if you consider that they have some advantages that the closure version doesn’t have:

2. Is there any semantic difference between these two versions?

Yes.

• You can’t inspect private fields directly (duh). This also means you can’t easily clone objects or do other kinds of reflection on them.
• Accessing a field via an object property instead of a direct reference allows you to use prototypal inheritance. The parts that matter are that:
  • You have a hard time overriding things in a subclass (variables in a closure are static, not virtual)
  • You can’t add other methods latter that use these hidden fields (since they are only accessible inside the constructor function). Particularly nasty for subclassing.

3. Are there any traps on using a closure like this?

Most Javascript engines today are less performant on code with lots of closures compared to code that uses prototypes. Not a “real” reason for a difference (since LISP engines have been fine with closures since forever) but something you will have to live with.