thiskeyword, and the associated problem of rebinding functions to another
newkeyword, and the workarounds people use to dodge them
To be clear, I adopted the style of the module pattern used by Mike Bostock, who presumably got it from earlier figures, and so on. Usually the variable-containing and scope-control bits of this pattern get the most attention - this sheds some light on other benefits that touch browser and async code as well.
this to refer
to ‘this instantiated object’.
every time that you call
Car(). Notice that, unlike the
method, there’s no
What are the essential bits?
The most common annoyance with
this is in event handlers, because they
turn this into the element that’s the source of the event.
So let’s say that you’re creating a simple counter, that attaches to a DOM element being clicked. The classical version might look like
This looks valid, but isn’t. Clicking on
increment repeatedly and then on
‘tell’ will tell you that Counter’s value is still 0. Why? Because
Counter.prototype.increment runs, but the value of
this in that
context is the DOM element of the
increment button, not counter.
A typical fix to this is to change the line to include
bind, a function
that changes the value of
this in a function for any time that it runs
in the future. Since this isn’t IE-safe, it’s more popular to use
_.bind from underscore.js or
jQuery.proxy() in the place
convenience methods like
bindAll that let you rebind a whole
bunch of functions at one time, so you can totally forget about
this problem. But it’s still there, and when your code leaves
that land, it’s a valid annoyance.
Here’s the other way to do this functionality:
This is a mixed bag, but there are some good examples of why it’s awesome. Let’s say you have a library that manages a set of markers on a map.
Of course, this will require the functionality of adding a marker
to the map. With a classical object, in most cases an uninformed
or adventurous user could see that
.markers is exposed and just
.markers.push(newmarker) it into the object.
The literal pattern lets you be much more paranoid, with a setup like
For instance, the code
to shorten the names of
single-letter names - there’s no way that you’ll be able to access them, so
the names can change. By contrast, after minifying the code:
The long function names
remain in their entirety.
As far as speed. Creating object literals is faster than instantiating
objects with constructors in most browsers, as this jsperf test from Mike Bostock
But dispatching method calls on those objects is slower.
But unless you’re doing some very serious, millions-of-iterations
the biggest worry.
In V8, small, prototype-based objects tend to out-perform
literal objects created with the module pattern - good insights can
be found in [this bit of Lars Bak's talk on the subject](https://www.youtube.com/watch?v=hWhMKalEicY&feature=youtu.be&t=48s)
and the aha moment for objects versus arrays came from reading
this bit of pre3d.js.
As far as the abusable power to do private members. There can be the feeling that you start off with an object like
And end up exposing a, b, and c, after realizing that private things couldn’t be private. So, if nothing else, this method requires an extra thought process to consider the level of encapsulation needed.
I rarely encounter the problem of really extending classes. Ben Cherry’s linked article has one possibility, and you can also just use an object that uses another object internally - like how Wax’s interaction lib is used in specialized API-specific controls which ‘customize’ the object internally. This is the idea of using composition over inheritance.
As far as the
instanceof problem - with classical objects, when you
var x = new baseballbat(), then
x instanceof baseballbat returns
x instanceof foo returns
false. Every once in a blue
moon this is handy, but it often runs into the same problems as strongly-typed
languages, in which direct class-equivalence isn’t all that importance
and it’s more likely you want to ask whether the object has methods or
properties you need in your code, not its origin.
For instance, in a large-scale project like Carto,
which required object identities, a chain of inheritance meant that the
only sensible way to do identity was to add a
.is member with a flag
telling what the value should be interpreted as. Except in the most extreme
cases, I don’t see much
instanceof use in the wild.
For objects that you’ll want thousands of, it might be a better option to either go with literal objects - for instance, the data types in Modest Maps would probably become simple arrays and their methods could easily become part of a singleton object. John Firebaugh confirmed this with a test that shows that for objects with many functionst that are initialized many times, there’s a serious (5x) difference in memory usage, due to more heap closures. So, it makes sense to use the module pattern for smaller objects, like UI widgets, map objects, and so on, while other techniques work well for atomic data, like pixel measures or nodes in a tree.
Have more ideas on this subject? Let me know over email or by tweeting at