In C#, we have implicit and explicit conversions. In both cases the idea is that we, the readers of the code, are not surprised by any conversions that happen. That’s why we can freely intermix ints with floats in a floating point calculation and everything turns out just fine. The ints are implicitly converted to floats (there’s no data loss) and the calculation comes out right. However, when there’s a possibility of some kind of data loss (say, converting a ulong to a long variable) you have to explicitly state the conversion in order to say “yep, I know what I’m doing; move along, nothing to see here.” Of course, the explicit conversion does come with an implied contract – that you have, you know, actually determined that the possible loss of data is benign – but otherwise just have at it.

In JavaScript type conversions are known as coercions. Variables will be coerced automatically into values of another type to make the statement or expression work. Unlike C#’s implicit conversions where there’s no data loss, JavaScript’s coercions can really wreak havoc if you are not paying attention.

One great example I’ve already talked about is the use of the double-equals (equality) comparison operator. If the two sides are evaluated to be of different types, JavaScript will coerce one or both sides to make sense of the comparison. So we get things like this:

var b;
b = 0 == "0"; // true, the "0" is coerced to 0
b = 0 == ""; // true, the "" is coerced to 0
b = "0" == ""; // false, duh, both sides are the same type

var o = {
  toString: function () {
    return "42";
  }
};
b = o == "42"; // true, the object is coerced to a string using toString()

As you can see, the first three assignments show that ‘==’ is not even transitive, going against everything you’ve ever learned; which, if nothing else, should keep you up at night. That’s why the recommendation is to always use triple-equals (identity) as a comparison operator since it does not do any coercions at all. As a handy hint, if you really, really want to use “==”, then you can force the coercion you want rather than the one you get:

var b;
b = "" + x == "" + y; // String comparison
b = +x == +y;         // Number comparison
b = !x == !y;         // Boolean comparison

But really, forget I told you this and just use “===”. Really – you can just thank me later.

At CodeMash 2012, Gary Bernhardt did an awesomely funny presentation called Wat. Watch it, and then come back here. I’ll wait.

The JavaScript parts of Gary’s talk are all to do with coercions. The first one was “what’s [] + []?”, or, in other words, what’s an empty array plus an empty array? The answer is the empty string, and the reason is not that difficult when you think in terms of coercion. The binary “+” operator in JavaScript, like C#, has two meanings: add a number to a number, and concatenate a string to a string. In C#, that’s all there is to it: you’ve got to make sure the types match and you’re done. However, in JavaScript, if the left-hand side and the right-hand side don’t make sense when used with “+”, they get coerced, usually to strings. Since [].toString() is the empty string (toString() on an array will list the contents of the array as strings separated by commas), you get the result Gary showed.

The second example, [] + {}, should now be obvious. Again, values are getting coerced to strings using the toString() method. (The answer is the string “[object Object]”, the default result of calling Object.prototype.toString().)

The third example, {} + [], caught me out at first. To my mind, it should be the same as the second example. This is where it gets seriously wacky. This code:

var result = {} + [];
console.log(result); // "[object Object]
console.log(typeof result); // "string"

produces the results shown in the comments; exactly the same as before. Yet, typing {} + [] in the Console in Firebug produces Gary’s answer of 0. What’s going on?

The answer is that the first {} in the statement is not evaluated as an object, but as a block. It’s an empty block (open brace, no code, close brace) and does nothing. So we’re left with +[]. The unary plus is numeric only, and so the empty array gets coerced to a number, in fact to 0. (In essence, it’s coerced to an empty string, and coercing an empty string to a number produces 0.)

The fourth example ({} + {}) is (a) an empty block as before, and (b) an object coerced to a Number (OK, it coerces to “[object Object]” as a string,  and that string, when coerced to a number, produces NaN).

Mind you, if you ever rely on any of this stuff, please let me know so that I don’t work on the same code as you. Thanks!

(For background, please check out parts 1, 2, and 3 before reading this post.)

One of the problems about private local variables inside closures is that you can’t see them. Well, duh, you might say, that’s what private means after all. Point taken, but there’s one scenario where it would be really nice to be able to check those enclosed (enclosured?) variables: debugging.

Now, I’m not going to get into the whole argument here about debugging versus testing. I’m of the firm belief that you should be writing unit tests as you go along (and I’m only not doing it here because the code I write for these posts is mainly pedagogical in nature). Once you have properly built a supporting unit test structure around your code, it shouldn’t matter what your local variables contain: the unit tests will test your external interfaces and if they work as expected then you’re gold as far as the behavior of your code is concerned. Anyway…

Back to our stopwatch example – the initial simple version. Now, I will admit that, as written, it’s ruddy hard to unit test this little object. That’s because I’m embedding, essentially, a random process in the middle: the current time. To properly test this I should extract out the code snippet that gets the current time (the weird-looking +new Date() statement) and build it in as an external interface that I can then mock. But let’s say I want to debug this code after I’ve called start() and before I call stop(). As written, there’s no way I can inspect the local variable startTime if I’m in a debugger. The stopwatch object is opaque.

Enter the debugger keyword. This is a reserved word in JavaScript and is designed to trigger a program breakpoint when executed. If there is no JavaScript debugger present, it’s just ignored, but if you are running under Firebug or whatever developer tools your browser provides (I use Firefox myself) the debugger will gain control and hand control over to you.

So what, you may say. Whether you have a manual breakpoint or use this fancy debugger statement, you still have the same problem: you can’t see inside the opaque stopwatch object. True. . . unless you execute the debugger statement inside the context of the closure itself.

Let’s add an inspect() method to the stopwatch object:

var stopwatch = (function () {
  var startTime = -1,

  now = function () {
    return +new Date();
  },

  start = function () {
    startTime = now();
  },

  stop = function () {
    if (startTime === -1) {
      return 0;
    }
    var elapsedTime = now() - startTime;
    startTime = -1;
    return elapsedTime;
  },

  inspect = function () {
    debugger;
  };
  
  return {
    start: start,
    stop: stop,
    inspect: inspect
  };
}());

Notice that this new function is inside the closure. If we call stopwatch.inspect() from the Firebug console, for example, the breakpoint will be triggered, and will be triggered inside the context of the closure. We will be able to see the value of startTime (and modify it if required).

In Firebug, you get something that looks like this:

Now the program execution has stopped inside the closure, you can inspect the value of startTime to your heart’s content.

Now, I’ll be the first to recognize that this technique is a little invasive – after all, you have to write this special function and expose it publicly – but it does nicely solve the “I can’t inspect the values of the locals inside my closure/module” problem.

Way back in March 2009, I wrote a quick post about the JavaScript arguments quasi-array, about how the interpreter sets it up on every call to every function to hold the arguments passed to that function.

Although I blithely talked about the fact that arguments was array-like, it wasn’t a real array (it’s not typeof Array) and didn’t have methods like pop() and the like. In fact, it only really has a length property and a bunch of properties named ‘0’, ‘1’, ‘2’ and so on. So it’s easy to iterate over the elements, er, properties, but that’s essentially it.

It’s actually quite easy to convert it to an array and then use that. You don’t even have to use the obvious for loop to do it either. You use the Array’s prototype’s slice() method:

var argsArray = Array.prototype.slice.call(arguments);

Since arguments does not have the slice() method, we have to use the call() function to call it on arguments (this is an application of the apply invocation). slice() returns part of an array as an array, but If you don’t pass any arguments to it – start index, end index – the function returns all of the elements instead. Which is, if you think about it, what we want.

So, if you have, say, a logging library for your code, and you want to log the values of the arguments to a particular function, you could do something like this:

var convertArgs = function (args) {
  return Array.prototype.slice.call(args);
};

var myLoggingLibrary = {
  logArguments: function (argsArray) {
    console.log(argsArray);
  } 
};

var someFunctionToTest = function (a, b, c, d) {
   // do something with the arguments; we’ll just print the first
   console.log(a);
};

var addArgumentsLogging = function (f) {
  return function () {
    var args = convertArgs(arguments);
    myLoggingLibrary.logArguments(args);
    f.apply(this, args);
  };
};

someFunctionToTest(1, 2, 3, false); // prints "1"

someFunctionToTest = addArgumentsLogging(someFunctionToTest);

someFunctionToTest(1, 2, 3, false); // prints "[1, 2, 3, false]" then "1"

With the addArgumentsLogging() function, I am not altering the function to be logged: I am merely creating a wrapper around it that does the logging and then calls the original function using the apply invocation. Notice how I’ve replaced the original function with the wrapped version. (Note also that the addArgumentsLogging function creates a closure over the parameter f.)

So there you go: how to convert the arguments quasi-array into a real array and then use it.

Now that we’ve seen the simple module pattern as well as ways to augment it, we should take a look at one final piece of the puzzle.

Private fields, as we saw in the last installment, can be a real issue. Sometimes, dammit, we’d just like to refer to that private local variable when we’re augmenting a module object. Just a peek you understand, and we’d make it private again immediately we’re done augmenting, so that the code using the module object doesn’t see this private variable. Unfortunately, given the way we’ve implemented privacy through closures this remains a bit of a problem.

Let’s see what we could do given a blank slate. Let’s create an object called secretData and make its properties the internal data we want to save and to share amongst our augmentation code. Obviously, we’d have to make this a normal property so that other code could use it with the augmentation pattern. Here’s the changed stopwatch:

var stopwatch = (function () {
  var $sd = {},

  start = function () {
    $sd.startTime = $sd.now();
  },

  stop = function () {
    var elapsedTime = $sd.peekElapsedTime();
    $sd.startTime = -1;
    return elapsedTime;
  };

  $sd.startTime = -1;

  $sd.now = function () {
    return +new Date();
  };

  $sd.peekElapsedTime = function () {
    if ($sd.startTime === -1) {
      return 0;
    }
    return $sd.now() - $sd.startTime;
  };

  return {
    start: start,
    stop: stop,
    secretData: $sd
  };
}());

Nothing to it so far: for the first change I declare a local variable called $sd and then add startTime and now() to that object. I also refactored the code a little bit so that there’s a new function that can just calculate the elapsed time. Since we’re going to share this behavior, we might as well isolate the complicated calculation into its own function. The returned object now has a new property called secretData (which is anything but, at the moment) which is a reference to this local variable. The local variable is of course hidden by the closure.

Onto the tight augmentation code:

// Augmented stopwatch
var stopwatch = (function (sw) {
  var $sd = sw.secretData;

  $sd.laptimes = [];
  $sd.oldStop = sw.stop;

  sw.stop = function () {
    sw.lap();
    $sd.oldStop();
  };

  sw.lap = function () {
    $sd.laptimes.push($sd.peekElapsedTime());
  };

  sw.reportLaps = function () {
    var laps = $sd.laptimes;
    $sd.laptimes = [];
    return laps;
  };

  return sw;
}(stopwatch));

I first make a copy of the secretData property and then use that copy throughout for any local variables I need in the closure. Other than that, the code for lap() is much simpler (since I’ve made use of the method that returns the elapsed time), as is the overridden stop() method. The returned object still has the very public secretData property of course.

Now the fun bit. After the module object has been finally augmented, we call:

delete stopwatch.secretData;

Whoa. What this does is to delete the secretData property completely. But, notice something else: both closures created by the module pattern have made copies of the secret object already (they both called this copy $sd). The code in the closures still functions just as before since it makes no reference to the secretData property (except when executing the anonymous function to create the closure in the first place). Admittedly with some shenanigans, we’ve created some shared secret data across several closures.

If you don’t like the call to delete there, just create a method in the original unaugmented code (hideSecretData) that “cleans up” the public references to the secret data and call that instead. This makes it a little more more readable:

var stopwatch = (function () {
  var $sd = {},

  start = function () {
    $sd.startTime = $sd.now();
  },

  stop = function () {
    var elapsedTime = $sd.peekElapsedTime();
    $sd.startTime = -1;
    return elapsedTime;
  },
  
  hideSecretData = function () {
    delete this.secretData;
    delete this.hideSecretData;
  };

  $sd.startTime = -1;
  $sd.now = function () {
    return +new Date();
  };
  $sd.peekElapsedTime = function () {
    if ($sd.startTime === -1) {
      return 0;
    }
    return $sd.now() - $sd.startTime;
  };

  return {
    start: start,
    stop: stop,
    secretData: $sd,
    hideSecretData: hideSecretData
  };
}());

and then all you need to call is this to make the intent of the code clearer:

stopwatch.hideSecretData();

After this, not only will the secret data have been hidden, but also the method that hid it will have vanished.

(Part 1, Part 2 of this series.)

Last time I talked about the simple module pattern. This is where you create a function that returns an object with behavior and state and that behavior and state is implemented (and made private) by using a closure. We showed this by using the module pattern to create a stopwatch object.

Let’s now see how we can extend this stopwatch object by adding the facility to have lap times. This gives us the ability to use the same stopwatch to time a sequence of time-consuming actions, rather than creating a new stopwatch every time. The only caveat is that we can’t modify any of the code we’ve already written.

We’ll assume then that we have a new stopwatch object created from the previous code. We need to add a lap() method to record the time since the start or since the last lap. We also need a reportLaps() method that will return an array of lap times. One way to do this would be to create a brand new wrapper object (call it, say, a lapwatch) that uses the already created stopwatch internally as a delegate. In other words, the new lapwatch object would delegate all timings to the internal stopwatch but keep its own lap times. Perfectly doable but it’s hardly extending the original stopwatch object.

What we’ll do is to apply the module pattern again, but this time not to create a new object. Instead we shall augment the existing object. So the first change is to pass in the existing object to our anonymous function.

(function (sw) {

  // some code that operates on sw

}(stopwatch));

We have another auto-executing anonymous function, but this time it takes a single parameter: the stopwatch object. Inside the function, the parameter is known as sw for convenience’ sake. We assume that the as-yet-unwritten code will be modifying sw (and hence the external stopwatch). You could also return sw and re-assign it to stopwatch if you wanted, much like we did previously.

Now we can write the code that provides and reports the lap times.

(function (sw) {
  var laptimes = [];

  sw.lap = function () {
    laptimes.push(sw.stop());
    sw.start();
  };

  sw.reportLaps = function () {
    var laps = laptimes;
    laptimes = [];
    return laps;
  };
}(stopwatch));

As you can see, we have a local array to store the lap times and we add the two new methods to the existing object. The function forms another closure and provides a new private variable. The lap() method is a bit of a hack: since I stipulated that we couldn’t change the original object and since we have no access to the startTime variable, I had to stop the stopwatch to get the elapsed time and then immediately start it again. A better solution perhaps would have been to add a Peek() method to the original code, just so we can see the current elapsed time without stopping the stopwatch.

And here’s some dummy code that exercises this augmented stopwatch:

var i;
stopwatch.start();
for (i = 0; i < 100000; i++);
stopwatch.lap();
for (i = 0; i < 200000; i++);
stopwatch.lap();
for (i = 0; i < 300000; i++);
stopwatch.lap();
console.log(stopwatch.reportLaps());

This pattern is typically known as the Tightly Augmented Module Pattern. We pass in the current object and the function forms another closure over it to modify it. For this code to work we *must* declare the original code first and then this code. If they are in different source code files (the usual case), we must declare the stopwatch code file first, and then this augmented stopwatch code second. That way, the JavaScript interpreter will execute the code in the proper order; the augmentation code won’t get run on an undefined variable.

A slight modification that we can’t really show with our stopwatch example is the Loosely Augmented Module Pattern. With this pattern we’re usually building some kind of utility object or a namespace that contains a whole bunch of other objects that do some work. These other objects don’t require or interact with each other. For example:

var jmbNamepace = (function ($j) {
  $j.date = { ... };
}(jmbNamespace || {}));

--- 

var jmbNamepace = (function ($j) {
  $j.regex = { ... };
}(jmbNamespace || {}));
 
---

var jmbNamepace = (function ($j) {
  $j.url = { ... };
}(jmbNamespace || {}));

Each of these three code segments could be run before any of the others, and each could be omitted, if needed. If they were all in different source files, those source files could be loaded in any order, and only those needed could be loaded. The magic is in the expression jmbNamespace || {}. What this says is “evaluate the expression to be equal to jmbNamespace if it is defined, otherwise evaluate to an empty object”.

Going back to our stopwatch example, notice that there’s something buggy about it. If I’d called stop() on the augmented stopwatch at the end of the last “lap”, the time for it won’t be recorded in the array of lap times. We should allow for this possibility. The way to do this is through an override: we have to override the behavior of stop() if we are using the stopwatch to time laps. Here’s how to do that (and note I’ve changed the definition of the anonymous function to return the augmented stopwatch object to show that this is an equally valid application of the Tightly Augmented Module Pattern):

var stopwatch = (function (sw) {
  var laptimes = [];
  var oldStop = sw.stop;

  sw.stop = function () {
    laptimes.push(oldStop());
  };

  sw.lap = function () {
    sw.stop();
    sw.start();
  };

  sw.reportLaps = function () {
    var laps = laptimes;
    laptimes = [];
    return laps;
  };

  return sw;
}(stopwatch));

The first new thing that happens is that we copy the function object referenced by the stopwatch’s stop() method and save it in the local variable oldStop. (The joys of first-class functions or “functions are objects”!) We then replace the stop() method with a new one that pushes the final lap time onto the array and we call the old stop function to get that final lap time. The lap() method also has to change: we can now just call the stopwatch object’s stop() method to do our work since it’s now rerouted through our override. All these shenanigans are of course hidden from view inside the closure.

Next time we’ll close off this mini-series on the module pattern with some final features.

(Part 1, Part 3 of this series.)

If you recall, JavaScript closures are an extremely powerful concept in the language. By using JavaScript’s rather peculiar scoping rules, closures are a way of creating private variables and functionality for an object. The module pattern builds upon this feature.

A quick recap on scope in JavaScript may be in order. Scope is the means by which programmers limit the visibility and the lifetime of their variables and parameters. Without scope, all variables would be global and visible everywhere. In C#, scope is introduced by braces: you can declare a new variable inside some code in braces — a block — and that variable would not be visible outside the block, and in fact would be destroyed once execution reaches the closing brace. These braces can be the braces surrounding the code in a method, or they can be the braces delineating a block for an if or a for statement, and so on. The essence of scope in C# is: declare a variable inside a block and it won't be visible outside the braces enclosing the block. (For full details about scope in C# you should read section 3.7 of The C# Programming Language (Fourth Edition) by Hejlsberg et al. There’s roughly eight pages of discussion on scope.)

In JavaScript, there is one basic rule: functions define scope. If you declare a variable in a function, it is visible anywhere inside that function, including inside any nested functions, even before it was declared. It is not visible outside the function. Since nested functions are also variables, they will also be visible anywhere in the enclosing function, even before they are declared. In essence, JavaScript hoists all variables to the top of the enclosing function so that they are declared before they are set with a value. This is like the lexical structure of Pascal with its var blocks, except that this hoisting occurs automatically in JavaScript.

Note that by nested functions, I mean functions nested in a lexical sense not in an execution sense. In other words, if function A calls function B, it doesn’t mean that B can suddenly ‘see’ the variables declared in A. For that to happen, B must be coded within the source code for A. It’s the lexical nesting that provides scope.

Let’s see this in code:

var outerFunc = function (paramOuter) {
  // Visible: paramOuter, varOuter
  //          nestedFunc1, nestedFunc2
  var varOuter = 42;

  var nestedFunc1 = function (paramNested1) {
    // Visible: paramOuter, varOuter
    //          nestedFunc1, nestedFunc2
    //          paramNested1, varNested1,
    //          nestedFunc1inner
    var varNested1 = false;

    var nestedFunc1inner = function () {
      // Visible: paramOuter, varOuter
      //          nestedFunc1, nestedFunc2
      //          paramNested1, varNested1,
      //          nestedFunc1inner, inner1
      var inner1 = "hello";

    };
  };

  var nestedFunc2 = function (paramNested2) {
    // Visible: paramOuter, varOuter
    //          nestedFunc1, nestedFunc2
    //          paramNested2, varNested2
    var varNested2 = false;

  };
};

It’s not exactly an example of some edifying code, but it gets the point across. If you look at the nestedFunc1inner function, you can see that all of the variables from the outer function are in scope as well as all the variables from the immediate parent function as well.

The nifty thing about these scoping rules is how well it plays along with closures. A closure encapsulates a function’s environment so that it can continue to exist as an object even after the function terminates. In C#, you see this most of all with lambda expressions and anonymous delegates, but with JavaScript you see it all over the place. jQuery is, in essence, one gigantic closure.

Let’s suppose we have to write a stopwatch object, which we’re going to use to time sections of our JavaScript code. The object should have a start() method that starts the stopwatch ticking, a stop() method to stop the watch (and which should also return the number of milliseconds elapsed). Without closures we’d probably write something like this:

var stopwatch = {
  startTime: -1,

  now: function () {
    return +new Date();
  },

  start: function () {
    this.startTime = this.now();
  },

  stop: function () {
    if (this.startTime === -1) {
      return 0;
    }
    var elapsedTime = this.now() - this.startTime;
    this.startTime = -1;
    return elapsedTime;
  }
};

Notice that I have a helper method called now() (that construction of +new Date() looks too weird in actual code – what does it do again?) as well as an internal field that records the start time of the stopwatch. Unfortunately although this object nicely encapsulated these two members, they are public, fully visible. We have not hidden them. A user of the stopwatch object could access them, change the variable, replace them, whatever. Also, I hate to say it, but all those required references to this doesn’t half obfuscate the code and make it long-winded.

Enter the module pattern. With the module pattern, we create an anonymous function and execute it automatically. The function will return an object that will be our stopwatch object. Let’s look at this step-by step. First we create the outer anonymous function and auto-execute it. For now we’ll have the function return an empty object.

var stopwatch = (function () {
  // other code to be added here
  return {
    // define some fields
  };
}());

Nothing too drastic so far, I’m sure you’ll agree. Now the fun bit starts. Let’s add back the original stopwatch code, altering it so that it makes sense as local variables and nested functions.

var stopwatch = (function () {
  var startTime = -1,

  now = function () {
    return +new Date();
  },

  start = function () {
    startTime = now();
  },

  stop = function () {
    if (startTime === -1) {
      return 0;
    }
    var elapsedTime = now() - startTime;
    startTime = -1;
    return elapsedTime;
  };

  return {
    // define some fields
  };
}());

As you can see all of those annoying this references have gone since there is no enclosing object any more. Instead we can rely on function scope to resolve references to variables. For example, in the start() function we can reference the outer anonymous function’s startTime local variable. For that matter, the same applies to the stop() function. The final step is to make sure that the returned object has the required two methods, start() and stop().

var stopwatch = (function () {
  var startTime = -1,

  now = function () {
    return +new Date();
  },

  start = function () {
    startTime = now();
  },

  stop = function () {
    if (startTime === -1) {
      return 0;
    }
    var elapsedTime = now() - startTime;
    startTime = -1;
    return elapsedTime;
  };

  return {
    start: start,
    stop: stop
  };
}());

The code that creates the new returned object looks a little weird until you read it as “this new object has a stop property whose value is the internal stop() function object, etc.”

The returned object makes use of the closure formed by the anonymous function. The object’s two properties (methods) will call the nested functions inside the closure and those, in turn, will make use of the outer function’s local variable startTime. We’ve essentially created some private members: a local variable and a now() function. These two members are inaccessible outside of the closure.

It must be admitted that the code as written assumes that our stopwatch object is going to be a singleton; after all, we’re auto-executing an anonymous function and it’s hard to do that twice in a row. If you have need of several stopwatches, then the best thing is to assign that anonymous function to a variable called createStopwatch, and then you can call it ad nauseam to create as many stopwatches as you’d like.

var createStopwatch = function () {
  // same code as before
  return {
    start: start,
    stop: stop
  };
};

var stopwatch1 = createStopwatch();
var stopwatch2 = createStopwatch();

Next time, we’ll take a look at how to augment an object created with the module pattern.

(Part 2, Part 3 of this series.)

I can’t believe that I haven’t posted an article on how to call functions in JavaScript and what this gets set to for each of the various invocation patterns. It’s one of those things that catches people out periodically, so it’s well worth discussing at length.

There are four different ways to call or invoke a JavaScript function: method invocation, function invocation, constructor invocation, and apply invocation. Each of these invocation patterns results in this being set to a different object inside the function. In C#, there is never any doubt what this refers to: it’s the object (the instance) on which the method is called. Using this is entirely optional, unless you are trying to resolve some possible ambiguity in the code (say, a parameter to the instance method has the same name as a field of the instance: in this case, to refer to the field you would have to use this). Of course, for a static method rather than an instance method, using this is an error and will be caught at compile-time.

Method invocation

Back to JavaScript. We’ll first talk about the equivalent to C#’s calling of an instance method: method invocation. This is just like the C# case: you’ve got some object and you call a method of that object. The this variable inside the function will be set to point to the object you’re calling the method on. In essence, pretty much exactly the same as C#.

Let’s look at a simple object called printer. When you call the log method of printer passing in some other object, it will print the object passed in as well as the number of times the printer object has been used.

var printer = {
  callCount : 0,

  log : function(obj) {
    console.log("---");
    console.log(obj);
    this.callCount += 1;
    console.log("--- (log number: " + this.callCount + ")");
  }
};

As you can see, a very simple object with one field (callCount) and a log method. The log method will print the object, increment the field, and then print a line showing how many times it has been called. The use of this is not optional as in C#; it must be used, otherwise the interpreter will try to resolve it by walking up the scope chain to the Global Object (which in browser JavaScript is window). If you like, this bypasses the normal scoping rules in JavaScript.

Here’s a quick example of how to call it.

var someObj = {a:42};

printer.log(someObj); // prints 1 as log number
printer.log(someObj); // prints 2 as log number

The fun thing about JavaScript is that functions are objects. We can pass them around at will. Here’s a new (empty) printer object that I then create the same field for. I can then create a log method by copying the printer.log function.

newPrinter = {};
newPrinter.callCount = 41;
newPrinter.log = printer.log;

newPrinter.log(someObj); // prints 42 as log number

Function invocation

The next way of calling a function is using function invocation. This is easy in concept – just call the bare function, not using an object – but it is the invocation pattern that causes the most problems and bugs. The reason is that the this variable gets set to the Global Object. Let’s take a look at a couple of examples. Firstly though, let’s define a simple function that returns true if the passed in object is the Global Object.

var isGlobalObject = function(obj) {
  return (function() {return this === obj;}());
};

What? Did he say simple? Let’s take it slowly. First of all, isGlobalObject takes in an object and returns something. What it returns is the result of automatically calling an anonymous function. This anonymous function is called using the function invocation pattern we’re currently discussing and checks to see if this is equal to the outer obj parameter. In other words, this anonymous function makes use of the pattern we’re trying to demonstrate. (Note: because I did not hard-code window, this function will also work on node.js, where the Global Object is called something else.)

Before making moving on, let me emphasize a point. Automatically calling an anonymous function is one of the great patterns of modern JavaScript and hence in one of these types of functions this will point to the Global Object.

Now we can make up some example function and show that calling it using the function invocation sets this to the Global Object.

var doSomething = function (arg) {
  isGlobalObject(this) ?
    console.log("In this function, 'this' is the Global Object") :
    console.log("In this function, 'this' is something else");
};

doSomething(); // prints that 'this' is the Global Object

There is another common JavaScript coding pattern that can throw up bugs because people assume this points to the enclosing object rather than the Global Object, and that’s with callbacks. Let’s illustrate with setTimeout. I’ll write a ticker object that outputs an asterisk once a second.

var ticker = {
  show : function() {
    console.log("*");
  },
  start : function() {
    this.show();
    setTimeout(function() { this.start(); }, 1000);
  }
};

ticker.start();

If you run this code, you should see an asterisk, and then after a second you should get an error saying “this.start is not a function”. The reason is that the callback to the setTimeout function is an anonymous function and setTimeout’s code will call it using the function invocation pattern. The this variable will be set to the Global Object and not the ticker object, despite what a quick glance at the code might imply. Since window.start does not exist, you get the error message.

To solve this bug, we shall have to save the value of the this variable in the start method, and then use that local variable inside the anonymous function. Because in JavaScript scope is defined by function, the anonymous function will ‘see’ this local variable in its parent function.

var ticker = {
  show : function() {
    console.log("*");
  },
  start : function() {
    var self = this;
    self.show();
    setTimeout(function() { self.start(); }, 1000);
  }
};

ticker.start();

Notice that every time start is called, it is called using the method invocation pattern and we always save the object it’s called on in a local variable called self.

Constructor invocation

The third way of calling a function is using the constructor invocation pattern. The first point to make here is that you must use the new keyword when calling the function.

var Person = function(lastName, firstName) {
  this.firstName = firstName;
  this.lastName = lastName;
};

Person.prototype.print = function() {
  var name = this.lastName + ", " + this.firstName;
  console.log(name);
};

var me = new Person("Bucknall", "Julian");
me.print();

Here I’ve declared a function called Person, created a method via its prototype object, and then called the function using new. What this does is similar to C#: it creates a new object based on the template I gave. Person is not a class, even though creating a Person object looks like you’re creating an instance of a class. In essence, the new keyword will create a brand new empty object, set its constructor to the function, and then call the constructor. The this variable will be set to this new empty object.

The final unusual thing about constructor invocations is that the newly created and initialized object is returned by default; you don’t have to code up a return statement explicitly.

The big problem about the constructor invocation pattern is that you sometimes forget to use the new keyword. Constructors are normal functions, there’s nothing in the language that marks them as being anything special, and so suddenly the call turns into a function invocation. And we know all about those: this points to the Global Object. In my example: calling Person without new will create a two new properties on the Global Object (firstName and lastName), return and set me to undefined, and then crash on the next statement since undefined certainly has no method called print.

There is a bit of a hack that can get round this for you. Define your constructors like this, and you’ll avoid the problem of forgetting to use new.

var Person = function(lastName, firstName) {
  if (!(this instanceof Person)) {
    return new Person(lastName, firstName);
  }
  
  this.firstName = firstName;
  this.lastName = lastName;
};

In other words, if the this parameter is not an instance of Person assume that the caller forgot the new keyword and construct a new object properly and return it. If not, just proceed as normal for a constructor.

Apply invocation

The final way to call a function is to use the function’s apply or call methods. This is known as apply invocation. Yes, a function is an object, so it can have (and has) properties and methods of its own. Both apply and call work by calling the function on an explicit object that you supply. Arguments to the function are either passed one-by-one (call) or as an array (apply). (The way I remember which is which is to say Apply uses an Array because they both start with A.) The this variable is set to the first parameter of the call to call or apply. Here it is in action with our printer object from above:

var anotherPrinter = { callCount : 23 };
var someObj = { foo : 42 };

printer.log.call(anotherPrinter, someObj);
printer.log.apply(anotherPrinter, [someObj]);

All that’s happening here is that I’ve created an object (anotherPrinter) with a callCount field, and then applied the printer.log method to it, passing in some object to log.

Now playing:
Jarre, Jean Michel - Pleasure Principle
(from Geometry Of Love)

I’ll admit this one is really wacky, so sit yourself down and read through this slowly. It’s OK if you need to take a break for a breather and to clear your mind. I had to the first time I came across this little, er, hack.

The situation is this: you have an array and you need to shuffle the items in the array. Now, being the Knuth fan that I am, I would immediately reach for Volume 3 of The Art of Computer Programming, check what Knuth has to say about it, and code it up:

var shuffle = function (a) {
  var randomIndex, temp, i = a.length;
  while (--i) {
    randomIndex = Math.floor(i * Math.random());
    if (randomIndex !== i) {
      temp = a[i];
      a[i] = a[randomIndex];
      a[randomIndex] = temp;
    }
  }
};

In essence (and ignoring some error checking): counting down from the top of the array, select a random element in what’s left of the array, and swap over the elements. Knuth states and proves why this is the best way of shuffling an array.

Imagine my surprise when, during some surfing session one day, I came across essentially this version of a shuffle:

var shuffle = function (a) {
  a.sort(function () {
    return Math.random() - 0.5;
  });
};

Using the sort function to shuffle? Shoot me now.

Let’s look at this closely. The sort function can take a function as its first parameter. This function is supposed to take two parameters, a and b, and return a numeric value. If this is less than zero then a is sorted to a lower index than b (if you like, in some sense, a < b). If it returns a number greater than zero, the opposite occurs and b is sorted to an index lower than a. If equal, the elements are not moved with respect to each other (well, in theory, but in practice this tends not to happen; in essence, obeying this rule is the difference between a stable and an unstable sort). If this comparison function is missing, the sort function converts each pair of elements to strings and does a lexical comparison between them. This leads to weird effects like this:

var a = [1, 2, 4, 3, 7, 8, 60, 5];
a.sort();
console.log(a) // prints [1, 2, 3, 4, 5, 60, 7, 8]

…because the string “60” is lexically less than the string “7”. Ouch. BEWARE!

Anyway, what our funky comparison function is doing is returning a random number between –0.5 and 0.5. Half the time it’ll return a number less than zero (so the pair of elements are sorted in the “less than” sense) and half the time a number greater than zero (so the pair of elements are sorted “greater than”). And I would have to say it seems to work, although it scares the heck out of me.

Why? Well, for a start the browser’s implementation of sort is in all probability done with quicksort. Which particular flavor of quicksort is unknown (the different flavors would be how the pivot element is chosen). Not matter how it’s done exactly, one of the overriding assumptions being made in the implementation is that the comparison function does not lie. If a is less than b, the comparison will return less than zero, every single time. If it does lie, neither you nor I have any idea how it would behave.

Quick story to illustrate my misgivings. About 15 years ago, perhaps more, I used to be in charge of supporting a Delphi library called B-Tree Filer. It had a procedure that sorted a virtual array using a merge sort implementation. One of the parameters was called LessThan, and it was supposed to be a function taking two parameters and returning true if the first was less than the second, false otherwise. All of my support issues dealing with this procedure (“Hey, it’s not sorting properly. Your code sucks!”) were easily solved when I explained that “less than” did not mean “less than or equal”. Since then I’ve been ultra careful when dealing with sorts and quicksort is just one of those temperamental algorithms you handle with kid gloves.

So, my first point is this: shuffling via sorting may work in this browser and previous versions, but it’s not necessarily going to work in the next. You may be bitten and never realize it.

The second point to make is that fast sorts are O(n × log n), so so shuffling via sorting will also have this performance characteristic. Sounds fast enough, but the proper shuffle algorithm I presented above is O(n). It’s faster for bigger arrays (small arrays are too small to make a difference). Why use a slower algorithm when the correct algorithm is faster?

Like 99% of all jQuery users, I write the code I want executed when the document is ready like this:

$(function () {
  // code using $ for the jQuery function
});

Except… What happens if someone calls $.noConflict() and $ is no longer valid? Do I have to resort to using jQuery() all over the place, just to be sure?

Answer: no. It seems – and I only discovered this moments ago – the document ready handler gets passed the jQuery function as the first and only argument. You can write this instead:

jQuery(function ($) {
  // code using $ for the jQuery function
});

Or, if you are really paranoid:

jQuery(function ($, undefined) {
  // code using $ as the jQuery function
  // and undefined means what it says
});

Magic!

I was answering a JavaScript question on stackoverflow when a common usage scenario presented itself, one with a subtle gotcha that could catch you out. Perfect for a quick blog post. (Note: you could also view this post as an adjunct to my popular JavaScript callback posts (I, II, III).)

photo © 2006 Judson Dunn | more info (via: Wylio)My solution to the problem involved adding some extra precondition code to an existing event handler. The event was the plotclick event of the jQuery Flot charting library, so the original event handler code looked like this:

  $("#chart").bind("plotclick", function (event, pos, item) {
    // respond to the click 
  });

Pretty easy stuff. However in my solution I wanted to enhance the event handler so that some preconditions were checked and, if they passed, the original code could be executed. Simple enough: just add the preconditions to the code – which is what I did for the answer.

  $("#chart").bind("plotclick", function (event, pos, item) {
    if (item) {
      var dataPoint = item.series.data[item.dataIndex];
      if (dataPoint[2]) {
        // respond to the click 
      }
    }
  });

For one chart, meh, not a problem. Make the change and move on. For several, it gets a little clunky; all those complicated bits of cut-n-paste. What would be better would be to wrap the original function – somehow – and then call the wrapper. In other words, in my mind I was thinking of something like this:

  $("#chart").bind("plotclick", wrap(function (event, pos, item) {
    // respond to the click 
  }));

So that the minimal amount of change would be required. This would also work if the event handler were not an anonymous function.

What would this wrap function look like? Well, it takes a function with the required signature (that is, takes three parameters) and returns another function, the event handler, that is also of the required signature and that calls the original function. (Call these the wrapper and the wrapped.)

  var wrap = function (originalHandler) {
    return function (event, pos, item) {
      // extra stuff
      originalHandler(event, pos, item);
    };
  };

There is, however, one small problem with this code. I will admit that the first time I wrote it I missed the issue, and it was only through testing that I discovered the bug, so it’s not glaringly obvious.

I’ll stop a moment for you to think about it.

Found it? Give yourself a bonus point if you did. The problem is the this variable, the context of the wrapper, is not passed on to the wrapped. As written, the call to originalHandler is a function invocation, and the this variable inside the function will be the global object, not the context passed in for the wrapper function. With jQuery, the context will be the DOM element for which the event was triggered, and my code just blithely throws that away.

Let’s rectify that right now:

  var wrap = function (originalHandler) {
    return function (event, pos, item) {
      // extra stuff 
      originalHandler.call(this, event, pos, item);
    };
  };

So, going back to my particular case, I’d have:

  var wrap = function (originalHandler) {
    return function (event, pos, item) {
      if (item) {
        var dataPoint = item.series.data[item.dataIndex];
        if (dataPoint[2]) {
          originalHandler.call(this, event, pos, item);
        }
      }
    };
  };

So, I’d say the takeaway from this blog post is that—yet again—the fundamental concept that functions are objects (that is, you can pass them around, and create functions that return functions), and that you should be careful if you do so that you take care of the this variable, if needed.