(Over)thinking JavaScript objects 1

tally-clicker

I’ve always found JavaScript’s approach(es) to OOP a little cumbersome. I’m not talking here about prototypal vs. class-based OOP. Rather, I’m talking about the readability, etc. of the actual code you have to write to build objects. I want to take a few blog entries to try to put the maze into some kind of cohesive perspective.

I like to use a tally clicker to explore objects in languages I am learning. A tally clicker is a real-world object with a minimal set of features that are easy to implement and that map to basic but salient OOP concepts.

Object literals

I’m going to start this exploration with plain-Jane object literals. This is one of the canonical ways and often the first way shown to implement objects in JavaScript. Here’s how I might implement a tally clicker with a JavaScript literal:

// == Create a tally clicker ========
var myClicker = {

    // pseudo-private property
    _numClicks: 0,         

    // pseudo-private method
    _update: function() {
        console.log("myClicker1: " + this._numClicks);
    },

    // public methods
    click: function() {
        this._numClicks++;
        this._update();
    },

    reset: function() {
        this._numClicks = 0;
        this._update();
    },

    showInfo: function() {
        alert('I am "myClicker" and am at ' +
            this._numClicks + ' clicks.');
    }
}; // == End tally clicker ========

I might then stick something like this into the HTML:

<button onclick="myClicker.click();">Click</button>
<button onclick="myClicker.reset();">Reset</button>
<button onclick="myClicker.showInfo();">Info</button>

The object literal approach is a seductively easy and pretty readable way to build an object—but it’s got issues. Namely:

  • There’s no automatic initialization apart from property values.
  • It violates encapsulation because everything is public.*
  • It pollutes the global namespace (sort of). As is, the name of the object is in the global namespace.
  • The object abstraction doesn’t scream, “Reuse me!” (This may be a cognitive style issue more than anything else.)

In the next couple installments, I’ll consider some alternative implementations specifically with regard to the above criteria. For the moment, I will not deal with:

  • Inheritance-like stuff
  • “Class” (i.e., static) members*
  • Polymorphism

*An issue of religious importance.

Git tags

git-logo

If you are using git-gui to manage your Git repositories, you may be perplexed that you can’t find support for tags anywhere. If that’s you, then you might also be overjoyed to learn that tagging support is actually part of gitk, git-gui‘s sister app.

To create a tag, open the repository and branch you want in gitk. An easy way to do this is to use git-gui‘s Repository > Browse xxx’s Files menu items. Then in gitk, right click on the commit you wish to tag (on the actual text, not any labels) and select the Create tag from the context menu.

Once you get that sorted, you might next be perplexed that when you push your repository to the remote origin, tags don’t go along for the ride. That’s because, “By default, the git push command doesn’t transfer tags to remote servers.”

You can remedy this with some command-line foo. I have used the shell command:

$ git push origin --tags

to push all tags in a local repository to the remote.

Android VM Manager

I just released a tiny Qt widgets-based app that makes it more convenient to connect an Android virtual machine to your development environment. Here’s a quick (but possibly not quick enough) demo of configuring it to work with AndroVM and the Eclipse-based ADT Bundle:

I’ve successfully used it with Android-x86 as well. I gotta say that doing development with either of these VMs is much faster and more rewarding than using the emulator that ships with the ADT.

The code is available on my Bitbucket at https://bitbucket.org/mithat/androidvmgr and is licensed under the GPLv3.

Getting closure in JavaScript

wooden heart

If you’re coming from an imperative programming background, closures in JavaScript can be pretty hard to grok. Here is yet another attempt to explain them. It assumes you are familiar with how lexically scoped, imperative languages like C, C++, and Java work.

In JavaScript every function call creates its own lexically scoped context. Normally that context is destroyed at the end of the function call. However, you can keep that context alive by creating a closure.

The function inner below creates a closure. Because there exists a reference to the inner function from the calling code after the function returns, neither the inner function nor its context are destroyed. In other words, inner‘s context (including vars local to countFrom) lives on after the call to countFrom returns.

function countFrom(num) {
    var counter = num;
    var inner = function() {
        // return the value of counter before increment.
        return counter++;
    }
    // return a reference to the inner function.
    return inner;
}

var countFromOne = countFrom(1);
/* countFromOne now refers to inner()
   with a unique, persistent context. */

window.alert( countFromOne() );  // alerts 1
window.alert( countFromOne() );  // alerts 2
window.alert( countFromOne() );  // alerts 3

var countFrom42 = countFrom(42);
/* countFrom42 refers to inner()
   with different, persistent context. */

window.alert( countFrom42() );  // alerts 42
window.alert( countFrom42() );  // alerts 43
window.alert( countFrom42() );  // alerts 44

/* The context associated with the inner from
   countFromOne is not affected by the above. */
window.alert( countFromOne() ); // alerts 4

Once you get the basic concept, you should be able to follow other examples that show how they can be useful.

P.S. Neckbeards think not naming things is cool, so here’s an anonymousy version of the function above.

var countFrom = function(num) {
    var counter = num;
    return function() {
        return counter++;
    };
};

Git again

git-logo

I’ve finally gotten around to using Git instead of Mercurial on a project. So far it has been uneventful. I still prefer Mercurial because it treats all OSes as first class citizens and because I think the CLI is cleaner. My workflow doesn’t require a lot of branching, but Git fans seem to think it really shines there. My main motivation for going Git on this project is to get some experience with what will likely become the defacto standard DVCS.

I am mostly using git-cola git gui as a GUI frontend. Ironically, git-cola—like Mercurial but unlike Git itself—is Python powered.

The best resource I’ve found so far for working with Git if you already know DVCS fundamentals is Spherical’s “Git for the lazy.” Entp’s “Version Control for Designers” is pretty good too.

Gradually going Git?

I’ve been using Mercurial along with Bitbucket for project hosting for quite a while now. I’ve also grown quite fond of EasyMercurial to help manage my repositories. However, I have started to wonder if I should consider using Git as my defacto standard VCS.

I was originally attracted to Mercurial over Git because I got the sense that Git was an almost hackish amalgam of various scripts written in a variety of languages—and because it encapsulated a lot more “power” (read: “complexity”) than I saw myself needing. And while Linux was (and is) my main OS, Windows support for Git was sorta grimmish. Bitbucket’s hosting policies at the time seemed better than the closest Git-equivalent: GitHub (still do—BB’s unlimited private repos in particular), and Redmine offered an easy self-hosted project management solution including repository, wiki, issue reporting, etc. as well. Gitourious was available at the time but was (and is) feature incomplete compared to Redmine. I can’t remember if Trac supported either at this point.

So why consider changing? I’ve recently noticed what appears to be a mad rush to use Git in general and GitHub in particular–so much so that I’m wondering if Git is going to become the defacto industry standard soon. Changing to Git may not be as huge a deal as it might seem at first because Bitbucket, RhodeCode and Trac now let you use Git repositories in addition to Mercurial, and it seems Git’s support for Windows has improved. There are also a number of GUI Git clients available for all major platforms—though none of them seem as sweetly usable as EasyMercurial.

I may just try managing my next project with Git as a test-case. Worst case: convert the Git repo to Mercurial.