Caffeinated Simpleton

I did a little work on Cobra today and pushed the code around a little bit. Things that changed:

• Reorganized into a single closure. This helps keep internal details internal.
• Minimize with Closure Compiler
• JSLint now passes
  • I definitely recommend the JSLint VIM plugin if you’re a vimmer.
• Works in node.js (and most likely any server-side JavaScript implementation)
• Works in Internet Explorer.
  • I had never really tested this, but after fixing the things that JSLint found, the tests just passed.
  • Still need to test in IE 6. I don’t have a machine with IE 6 unfortunately.
• Added to documentation to clarify a few things.

At this point, I think the library’s safe for others to use. I tagged a 0.5 version, and I’ll be calling it 1.0 after it gets into a few more projects. Feel free to try it out!

You can find Cobra on github, or you can download version 0.5 now (tgz).

After posting cobra, one of the things I heard most was “don’t try to make JavaScript be something it’s not”. This is good advice, but I feel that in this case it was given too hastily. Cobra did not come out of a desire to make JavaScript more like Python, even though that was the result. Cobra came out of careful consideration of how to make JavaScript better.

Problems with JavaScript

I think most people who happen upon this lonely corner of the internet are already pretty familiar with the flaws of JavaScript, but I’ll mention a couple of the most glaring faults briefly.

Scope

JavaScript’s scoping rules are dumb. Variables default to the global scope unless told otherwise and the this keyword, which is supposed to point to the current instance, actually points to the global object unless told otherwise. These scoping rules cause huge problems for beginning JavaScript programmers and trip up the most experienced programmers if they aren’t paying attention. Since these odd scoping rules default to the global object, and not to some error state, errors can go by unnoticed for long periods of time.

Object Syntax

JavaScript claims to be a prototypal language. It lies. It’s a language that also has prototypes. In a true prototypal language, there are objects. Objects can be derived from other objects, either by copying the parent object or by linking to it. JavaScript does something similar with its objects’ built in prototype attribute. Its prototype points to an object that it replicates the behavior of. However, it doesn’t replicate this behavior until after you create a new object. Let me demonstrate with some unsupported features of JavaScript:

//This is my base object. It's a pretty simple 4 step dance.
Dance = {
    danceAround: function() {},
    steps: 4
}
 
// Let it be known that I wouldn't know what a tango was if I saw it.
// (Unless there was a rose in somebody's mouth, of course)
Tango = {
     steps: 34,
     dip: function(){}
}
// Now we pull some true prototype magic.
Tango.__proto__ = MyDance;
 
// This works then:
Tango.danceAround();

That’s true prototypal behavior. There’s no “new” keyword, just behaviors that can be stolen by other objects. Unfortunately, JavaScript was thrown together in (I believe) about 15 minutes, minus a 5 minute coffee break. The writers realized that people were going to flip if it didn’t resemble the popular languages of the time, so they implemented a prototype-based language, pulled the prototypes into a separate property, and added a “new” keyword. This led to syntax like the following:

//This is my base object. It's a pretty simple 4 step dance.
Dance = {
    danceAround: function() {},
    steps: 4
}
 
Tango = function() {
    this.dip = function();
    this.steps = 37;
}
Tango.prototype = Dance;

That’s not quite as pretty. Not only is it not as pretty, but there are some fundamental flaws. The dip function gets recreated every time a new Tango object is instantiated. This isn’t a big deal most of the time, but once a year the king has a ball and all of a sudden you have 1000 partners tangoing about, and with them, 1000 identical copies of the dip function.

Another flaw is that the prototype is not in the lookup path of the object until a new instance is instantiated. In this example, Tango.danceAround is not defined. This is because prototypes are not applied to objects until a new instance of the object is instantiated. A “class” in most languages is a definition of object behavior. Instances of a class are objects that behave as defined by the class. This is very close to how prototypes behave in JavaScript.

To summarize, JavaScript isn’t quite a prototype based language, it isn’t quite a class based language, and the syntax for doing either is ugly (for more on the ugliness, check out one of my previous posts).

Fixing the Problems

Fortunately, JavaScript is awesome in most ways. It’s so flexible that fixing the issues I’ve spelled out above is no problem.

Fixing Scope

You can’t entirely fix JavaScript scoping. Local variables which aren’t declared with var become global, and there’s nothing you can do about that.¹ You can, however, fix the this object. You can wrap any given object method in another method which asserts that its this will be set to a specific object.

MyDance = {
     danceAround: function() { console.log(this.cheer) },
     cheer: "WHOOO!"
}
 
MyDance.danceAround = function() {
    MyDance.danceAround.apply(MyDance, arguments);
}

This is called binding, and it makes this be what you would want it to be in most instances. My initial thought was to just bind all object methods to their instances at the time of instantiation. However, I don’t really like this idea. For one thing, it changes the language. For another, some libraries (I’m looking at you jQuery) like to mess around with this. If this is expected to be something, I do not want to change that. What I needed was a shadow this, a variable that was always present and always pointed to the instance of the object. Luckily, there was an easy solution. Python always passes its instance object as the first parameter of any method of a class. I could replicate this behavior easily using essentially the same binding code and have the code look familiar to Python programmers everywhere. So I did. Every instance method in Cobra has “self” passed to it as the first parameter, which is automatically guaranteed to be the instance, no matter what. No binding required.

Fixing Object Syntax

It is fairly easy to get JavaScript to behave like a true prototypal language. However, I don’t much care for true prototypal behavior since it still leaves an ugly syntax. My solution was to create a “Class” object that will implicitly apply prototypes.

Instead of:

MyNewThingy.prototype.doSomeStuff = function () {};
MyNewThingy.prototype.doMoreStuff = function() {};

We can do:

MyNewThingy = new Class ({
    doSomeStuff: function() {},
    doMoreStuff: function() {}
});

These end up being exactly the same, except the latter is clearer and cleaner in my opinion.

Inheritance is a bit tricky in the first case. To achieve prototypal inheritance, I have to do some magic.

Base = {
   basicStuff: function() {}
}
ThingyPrototype = new function() {
      this.doSomeStuff = function () {};
      this.doMoreStuff = function() {};
}
ThingyPrototype.prototype = Base;
 
ChildThingy.prototype = ThingyPrototype;

Now ChildThingy inherits from Base and has some of its own functions in its prototype. Cobra takes care of all of this for you:

Base = new Class({
    basicStuff: function() {}
});
ChildThingy = new Class({
    __extends__: Base,
    childsOwnStuff: function() {}
});

Again, I think this is a lot clearer and cleaner.

If you put both these fixes together, you end up with Cobra, which you can read all about here.

To wrap things up, augmenting JavaScript to fix its flaws is not a bad thing. The question is what to add. I haven’t used Cobra for anything yet, but it’s my current pet project. We’ll see if it really makes JavaScript that much more pleasant.

In my last post, I talked a bit about the problems I saw with trying to express new types and objects in JavaScript. It’s not so much that anything is difficult to do, it’s that doing different things requires very different (and sometimes very verbose) syntax. I tried a few different things to trick JavaScript into behaving differently, but in the end, I realized that perhaps just keeping things simple was the best thing to do. I wrote down a few small features for my little library.

• Classes. Not really the full blown classes of Java lore, but more a shortcut way of doing ClassName.prototype.functionName = function(args).
• Inheritance. I wanted my classes to support the prototypal inheritance built into JavaScript.
• Singletons. I wanted to be able to create single instances of classes without leaving a class around that might confuse people.
• Namespaces. I eventually realized that Object was good enough for this.

I also wanted some convention for how to deal with private methods and properties. In JavaScript, it’s pretty easy to have private members, and it’s pretty easy to do prototypal inheritance, but it’s a bit messier to do both.

My final bit of inspiration was Python. Python doesn’t care about privacy, it just trusts the developer not to mess things up. I like this philosophy. I also like the explicit self in python methods.  A lot of people don’t like self, but I think it makes it very obvious what instance your code is acting on. I took these things to heart and wrote Cobra, a class system for JavaScript that’s really simple and looks a whole lot like Python. Without further ado, let me show you some examples of Cobra.

Classes

/* This is our base class. In its initialization function,
 * all it does is set things that are true for
 * all living animals.
 */
var Animal = new Class({
    __init__: function(self) {
        self.breathes = true;
    }
});
 
/* Feline extends animal and overrides it's initialization function.
 * Notice that it calls it's parents __init__ function, just to be safe.
 */
var Feline = new Class({
    __extends__: Animal,
    __init__: function(self) {
        Class.super(Feline, '__init__', self);
        self.claws = true;
        self.furry = true;
    },
    says: function(self) {
        console.log ('GRRRRR');
    }
});
 
/* This is a cat. It inherits from Feline, and therefore also inherits from
 * Animal. It says something a bit different from most felines.
 */
var Cat = new Class({
    __extends__: Feline,
    __init__: function(self) {
        Class.super(self, '__init__', self);
        self.weight = 'very little';
    },
    says: function(self) {
        console.log('MEOW');
    }
});
 
/* Tigers are like most Felines except that they weigh a lot.
 */
var Tiger = new Class({
    __extends__: Feline,
    __init__: function(self) {
        Class.super(Tiger, '__init__', self);
        self.weight = 'quite a bit';
    }
});

If we try using these classes, you’ll see that they work as they should:

>>> sneakers = new Cat();
Object breathes=true claws=true furry=true
>>> sneakers.breathes
true
>>> sneakers.claws
true
>>> sneakers.furry
true
>>> sneakers.weight
"very little"
>>> sneakers.says();
MEOW
>>> tigger = new Tiger()
Object breathes=true claws=true furry=true
>>> tigger.says()
GRRRRR

You’ve probably noticed something very strange at this point (at least for the JavaScript world). Every instance method takes “self” as its first parameter. This parameter is the instance. Whether “this” is currently bound to the window or any other random object, “self” will always be the instance of the class. It’s a nice property, and you can still use “this” however you may wish. Just remember that your methods have to take “self” as their first arguments or weird things will happen.

Singletons

As I mentioned in my last post, I’ve had some issues creating singletons in JavaScript*.There is more than one way to do it, and you have to change a whole lot to go from one form to the other. If you no longer want your object to be a singleton, that might be a whole new refactoring pain. So I created a simple Singleton class that uses the same syntax as the Class type above, but it immediately discards its class and returns a single instance. This is nice because creating it is exactly the same as creating a class. You don’t have to think about it at all, and if you eventually realize a singleton was a bad idea, it’s trivial to convert it to a class.

var sanFranciscoZoo = new Singleton({
    __init__: function(self) {
        self.cats = [new Tiger(), new Tiger(), new Cat()];
    }
});

That’s pretty much it.

Namespaces, statics, and privacy

Everything else needs to be solved by convention. By looking at a method, it’s easy to tell whether it is static or not. If “self” is the first parameter, then it’s not static. So how do you create static methods? Well, for now, you don’t. If you have a group of static methods, stick them in an Object, which can be used as a namespace. You can even do the equivalent of C++’s “using”:

with (MyApp.Utils) {
    //this would normally be referenced as MyApp.Utils.utilityFunction();
    utilityFunction();
}

How about privacy? It’s handled the same as Python. Everything stuck into “self” is public, so use a leading underscore to indicate that others shouldn’t touch that data or method.

var Secretive = new Class({
    __init__: function(self) {
         self._doNotTouch = 5;
    }
    _doNotCall: function(self, add) {
        self._doNotTouch += add;
    }
});

I know that a lot of people don’t like the underscore approach (including JavaScript hero Doug Crockford), but it’s simple, consistent, and clear. I’m stickin’ with it.

Try It

I would love it if people would try it out on their own and tell me what they think. The source is available on bitbucket. Any problems can be reported in the comments or be filed here. There certainly might be some, I just whipped this up a few hours ago.

*When I say singleton, I mean a single instance of a class. In the design pattern world, this means that doing “new MySingleton()” would always return the same instance. I find that deceptive, so I just want it to throw an error when you try to make a “new” singleton.