Basic JavaScript* Patterns


I'm sure I'm dating myself more than I like when I say that I remember when "Structured Programming" was a new thing.  By the time I learned about it in my first Pascal class, I had been programming for a while in Basic.  I was psyched by the cleanliness and beauty of such wonderful features as while loops and if-then-else statements. Though it seems funny now, it took me some time before I really appreciated the significance of the "else" clause of an if-then-else.  I guess that's what happens when you're raised on Basic and Fortran IV (let this be a warning :-)

Meanwhile at home, programming for fun, I was still stuck with Basic as my only computing option.  It was frustrating to learn about all this cool new stuff, but not be able to use it.  At some point though, it occured to me that even though I didn't have if-then-else in Basic, I could program as if I did.  That is I could force myself to use a particular form for all my if-goto statements so that it corresponded in a predictable way to what I would write if it were an if-then-else.

For example, if I wanted to write

if a=b then
. . .

I could write

100 if a=b goto 130
110   x=1
120 goto 140
130   x=0
140 . . .

This pattern is straightforward, but it ends up with the 'then' and 'else' parts lexcially reversed (i.e. it looks backwards). If I want the subclauses to appear in the correct order I could instead tweak it like so:

100 if a=b goto 120
110 goto 140
120   x=0
130 goto 150
140   x=1
150 . . .

While this may seem a little more confusing, visually it is a little more sensible. I could just think of the first goto as "Then" and the second goto as "Else". Another approach might be to use the first option but always negate the condition so the 'then' part comes before the 'else' part:

100 if not a=b goto 130
110   x=0
120 goto 140
130   x=1
140 . . .

There are several possible solutions, but the key is, as long as I pick one, and use it consistently, the net result is something that's more like the Pascal if-then-else, and less like random goto's cluttering my code. It may take some head scratching to understand it that first time, but after that I can just recognize the pattern and treat it like structured code. It's still not quite the same as programming Pascal, but it gives me many of the benefits of more maintainable and debuggable code without the cost of buying a Pascal compiler, or for that matter a computer capable of running a Pascal compiler.

Now "Structured" programming features are old hat, and Javascript isn't lacking if-then-else. But these days everyone wants Object Oriented features, which are mostly lacking in Javascript. It doesn't have Classes, or Inheritance. It doesn't have Modules or even static variables. Heck, it doesn't even have integers. How can anyone write anything useful in this language?

Well, despite all the features that Javascript lacks, it is a wonderfully flexible language. So much so, in fact, that if we are particularly clever we can combine this flexibility with particular ways of programming that allow us to emulate features that aren't exactly in the language. And it turns out that particularly clever folks have come up with a variety of patterns to use to provide some of these missing features.

Consider an old standby for us C programmers, "static" variables. Static variables can be used (or misused) to keep data around that's local to a function (or other scope) but survives from one call to the next, like this:

int f(x) {
    static int i = 0;
    return ++i+x;

The "static" line specifies the initial value of 'i', it is not assigned zero on every call. In this case, the value of i used in the return statement corresponds to the number of times f() has been called, but i is not visible outside the function, which makes it different from (and safer than) a global variable.

If you wanted to do this in Javascript, it's a bit tricky. You could do this:

i = 0
function f(x) {
    return ++i+x;

But that's not quite the same thing. It appears to work the same, but now 'i' is a global variable, visible to everyone else. If someone else writes a different value to i (accidentally or on purpose) you may get odd behavior that can be difficult to sort out. So this may be a pattern, but not a very good one for the purpose of emulating static variables. So what would a good pattern look like? Well you would want it to use a locally scoped variable (so as to avoid overexposure) and you want it to be initialized once. It may be updated, but the same variable must stay around for later calls, preserving it's value from one to the next.

This post is getting long, so I'll leave cogitation of this as an exercise to the reader, but I'll look at some examples in the next installment.