The Integrated

Update, 7/1/2009: Switched code sections from manual coloring to an automatic syntax formatting plugin.

NOTE (6/20/2009): I didn’t intend to close comments on this post. The setting is on “enabled” and I’ve tried disabling and re-enabling them to no avail. Some glitch either with the WordPress 2.8 update or installing the new theme has screwed it up. If you have something to say about this post, drop me a line. My Gmail username is the same as everywhere else.

I haven’t been posting much lately; I have, however, been thinking about my future in some area of computer science, software development, and/or web development. And I’ve been tinkering more with JavaScript since my last post. One thing I’ve discovered how to do is baking event handling into your custom objects. This isn’t really innovative—all the major frameworks out there include it—but I had fun figuring it out on my own. Here’s the solution I arrived at.

I decided that the best way to store and fire event listeners was in an associative array, where the keys are the event names and the values are associative arrays linking IDs to functions. So, for example, a set of registered event listeners for an object representing a door might look like this:

Door.Event
   "Open"   => "a"  => function
   "Close"  => "b1" => function
               "c"  => function
   "Lock"   => (empty)
   "Unlock" => "b2" => function
               "d"  => function

The IDs here are just quick meaningless samples; the idea is that they come from and uniquely identify the object that registered their respective event listeners. They will be used by their originating object to unregister its own event listeners and not any other object’s event listeners if need be, since you may have multiple objects registering listeners for the same event, possibly even the same function registered as a listener by multiple objects. As an example of this, consider a card game. If there are two cards on the board that say, “Whenever a player discards a card, that player takes 5 damage,” you will have two instances of the triggered function (dealing 5 damage to the player) registered on an array of global events for “Discard”, and when that event is fired, both will go off and the function will be executed twice. Yet, if one of those cards is destroyed, it should remove its own specific instance of event listener registration—perhaps the other has had a spell cast on it modifying its effect, so it could matter which one gets deregistered.

Using this system, implementing event listener registration is simple.

Read the rest of this entry »

Update, 7/1/2009: Switched code blocks from manual coloring to an automatic syntax highlighter plugin.

Looking for JavaScript optimization tweaks, I encountered a claim that a decrementing do-while loop is faster than an incrementing for loop. I decided to do a quick-and-dirty test to see if there’s any clearly discernible difference. I wrote two scripts, each of which does the exact same thing: create 100,000 DIVs and append them to the body of the page. First we have the standard for version, then the do-while format that the site claimed was superior.

Version 1:

for (var i = 0, d; i < 100000; i++) {
  d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
}

Version 2:

var j = 0;
do {
  var i = 100000 - j,
      d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
} while (--j);

Note that the do-while has an extra line to set a variable i that will increment just as i does in the for loop, thus we get the same result of DIVs numbered 0-99,999. But what if the direction doesn’t matter? What if going backwards and numbering the DIVs from high to low is acceptable, or even what we actually want? The do-while proponent cited in support of his claim that computers are simply faster at counting down than they are at counting up. Whether that’s true or not, I don’t know. But it seemed worthwhile to include two more variants in my testing:

Version 3:

for (var i = 99999, d; i >= 0; i--) {
  d = document.createElement("div");
  d.innerHTML = "DIV #" + i + "";
  document.body.appendChild(d);
}

Version 4:

var j = 99999;
do {
  var d = document.createElement("div");
  d.innerHTML = "DIV #" + j + "";
  document.body.appendChild(d);
} while (j--);

I tested each version 10 times. Each test ran in a fresh instance of Firefox v3.0.6 with no other open tabs. Here are the results:

There seems to be no significant difference here between different looping techniques. In light of this, I’d call it a matter of clarity/readability and somewhat personal preference. If you have to increment, obviously the for loop is clearer to read. For decrementing, either seems fine, though I like the do-while.