Question

So, in answering another question on this site, I wrote a class for someone to create a BitArray instance in JavaScript. The code I posted looked like this:

var foo = function(param1) {
    this._member = param1;
    this.getMember = function() { return this._member; };
    this.setMember = function(val) { this._member = val; };
    this.alertMember = function() { alert(this._member); };
    foo.STATIC_CONSTANT = "some value";
}

One of the comments I received was a rather stern “You should absolutely add the methods to foo.prototype instead of this”. If I take that criticism and apply it to the above, it turns the code into:

var foo = function(param1) {
    this._member = param1;
}
foo.prototype.getMember = function(){ return this._member; };
foo.prototype.setMember = function(val) { this._member = val; };
foo.prototype.alertMember = function() { alert(this._member); };
foo.STATIC_CONSTANT = "some value";

My question is, what’s the difference here between the two approaches assuming foo will never be subclassed?

To be clear, I’m not advocating writing sloppy code – I credit the commentor with catching me being sloppy – but as I was conceeding to his correctness, it really did make me think – why should I prototype if I’m creating an effectively sealed class?

Is there some performance or functional consequence I’m missing here? Or when a class won’t be subclassed is using the prototype irrelevent?

Answer 1

There are various reasons. Firstly though I guess speaking of classes in JavaScript is misleading. There are no classes in JavaScript, but only prototypes.

Let us analyze what actually happens in your first approach and what happens in the second approach. When the code of the first approach is run it defines a function, which, when it is called as a constructor, will create a bunch of other functions and assign them to members of the newly created object. You should be aware that this is done every time you call the function. So if you call the function once, you will have one object with a total of 4 functions. If you call the function twice, you will have two objects with a total of 8 functions, and so on. Each time, you create a new object using this constructor you will create a complete set of functions for it. Each of those function will require memory. Also, modern JIT compilers trying to spot hotspots in your code might fail to identify those functions as hot spots, since instead of having one function that is called multiple times you have several functions where each is only called once. Additionally even if the JIT is able to spot those functions as hotspots, it will have to compile each of those functions separately which will require additional work.

That being said I believe the assumption “foo will never be subclassed” shouldn’t be valid. You cannot assume that others won’t want to inherit from your object or would like to augment the prototype of your object. This is currently not possible. Imagine I would like to change foo.STATIC_CONSTANT. I couldn’t, because each time I construct a new foo, it will override my changed foo.STATIC_CONSTANT again. Same is true for any other augmentation I might like to do.

All these problems do not arise in the second, correct object oriented javascript pattern.