Typical Noise

What I love about AngularJS - Part 1

2015-03-05T09:55:58.793000Z

I have been developing AngularJS applications for a several months now. I have really come to like the framework and this series of post will explain why. If you are looking for yet another tutorial on how to get started with AngularJS then this serious is not for you. Instead I intend to address a fundamental issue I have with the approach we have taken to writing software and how AngularJS has resolved my frustrations.

There are a lot of client side frameworks available. They all provide developers with some form of MVC pattern. Most of them simply re-hash the same patterns we have seen in server side frameworks like Rails, Django, and similar. Granted, most of them do offer new capabilities like some for of 1-way or 2-way data binding. They all still fall short when it comes to solving a fundamental issue I have with the way we structure and build applications today.

All of this frameworks a great, don’t get me wrong, but they all seem to focus on the MVC. It does not matter if the application is largely server side or client side. Take your typical Rails application. Everything will start out clean early on in your applications development. Your models are clean and small, the controllers are simple and you have no logic cluttering up your views. However, as the business goals evolve and more and more business logic is placed into your application that logic needs to go somewhere.

Most likely the first place this logic will appear is in the Controller. As time goes by the Controller gets more and more complex and soon it’s a 1000+ line beast. This is how I’ve seen a lot of early Rails applications structured. Lucky for the community this was quickly recognized as a bad approach. So all the business rules where moved out of the Controllers, leaving them to focus only on coordinating the interaction between the models and the views.

So where did that business logic end up? In the models. This is what coined the term “Skinny Controllers, Fat Models”. I argue that this logic does not belong in the model. A model shouldn’t know or care about the business rules defining how to transfer funds from one user’s bank account into another users bank account. A model should represent the data and that is it.

The business logic is the heart and soul of your application. It’s the entire reason for your application to exist. It is your Use Cases. Controllers, Models, Views, these are all part of the framework you are using they are not your application. So why do we treat these constructs as first class citizens and struggle to find a home for our business rules within our chosen framework?

AngularJS is a framework that solves this fundamental issue. Over the next few posts I will go into more detail about what makes AngularJS different and it how solves this problem.

Tmux Pro Tip

2015-03-05T09:55:59.069000Z

If you ever find that you've done something silly like

 bind -n o select-pane -R
 bind -n O select-pane -L

Then reloaded your tmux config live. Now when ever you type o or O you're switching panes left and right. No problem easy fix just remove the -n

 bind o select-pane -R
 bind O select-pane -L

Now it works as intended, but wait. Tmux does not automatically unbind keys. So how do you get your Os back?

Simply detach from the session and tell tmux to unbind them

 C-a d # note I have my prefix bound to C-a
 tmux unbind o
 tmux unbind O
 tmux attach

Prest-O!

I'm blogging with Postach.io

2015-03-05T09:55:59.431000Z

Since its so easy to create a new post, hopefully this means I will actually blog with some regularity again!

Ultimate macvim git commit setup

2015-03-05T09:55:59.689000Z

Took me a while to piece this together. There is a great tip in the macvim github wiki FAQ. Appending the following to your ~/.profile (or ~/.zshrc, or whatever)

export EDITOR='mvim -f --nomru -c "au VimLeave * !open -a Terminal"'

That --nomru switch tells vim not to add the commit message to the Most Recently Used file menu and the -c switch tells macvim to return the focus to the Terminal app when it quits.

This alone is quite nice, but soon enough you'll start to notice a rather annoying feature, that under normal circumstances is quite useful. If you stop editing a file and re-open the file for editing again Vim will remember the line you were last editing and return you to that line. This gets annoying with commit messages since it will often put your cursor somewhere down in the comments. There is a quick fix for this too though.

You can either add this line to your directly to your .vimrc

autocmd FileType gitcommit call setpos('.', [0, 1, 1, 0])

Or you can create a file called ~/.vim/ftplugin/gitcommit.vim and add the following to it.

call setpos('.', [0, 1, 1, 0])

Now vim will always place the cursor on the first line of your git commit messages.

Best Keyboard Shortcut Ever!

2015-03-05T09:55:59.889000Z

After using Adium for years and years I finally discovered what I consider to be the best shortcut I've learned in a long long time.

With Adium being the active window command + n will let you type a contact name and opens a new message window to that contact!

Super Simple Ruby Performance Tip

2015-03-05T09:56:00.177000Z

This tip is so simple it can be expressed with two characters, {}, curly braces. I've encountered this issue twice now. Once with some code in a project I work on as part of my day job, and once in a map reduce project I was evaluating.

As we all know the Ruby stdlib Logger class defines a bunch of useful logging methods (debug, info, warn, etc ) which take a string argument as the message to log. We can control which level of message is written to the log file quite easily, so that we only see the messages we care about appear in the log. This should be old news to any Rails or Ruby developer.

These Logger methods also take a block argument. When a block is given, it's return value is used as the message for the log file.

For instance:

<a href="http://logger.info">logger.info</a> "some message"
<a href="http://logger.info">logger.info</a> { "some message" }

They look similar but they do have one major difference tucked away in the source that is not made obvious in the rdoc. When using the block form, the block is evaluated after the level check is made. This is an important difference.

Lets have a look at some sample programs to get a feel for what I am talking about.

Benchmark.bmbm do |x|
  x.report("string form") {
    100_000.times do
      logger.debug "a simple string message"
    end
  }
  x.report("block form") {
    100_000.times do
      logger.debug { "a simple string message" }
    end
  }
end

# Rehearsal -----------------------------------------------
# string form   0.140000   0.000000   0.140000 (  0.146751)
# block form    0.330000   0.010000   0.340000 (  0.336446)
# -------------------------------------- total: 0.480000sec
#
#                   user     system      total        real
# string form   0.140000   0.000000   0.140000 (  0.144761)
# block form    0.320000   0.000000   0.320000 (  0.326912)

At first glance it looks like my point is invalid. Simple strings flat out beat the block form. But if you take a moment to think about what is actually happening then this makes sense. Ruby just needs to construct a string something that it can optimize, instead of bundling up all the necessary context data in a block.

But most of the time when you are logging you need to add some data to that message.

array = []
1.upto(10) {|i| array &lt;&lt; i}

Benchmark.bmbm do |x|
  x.report("string form") {
    100_000.times do
      logger.debug "a message with #{array.inspect}"
    end
  }
  x.report("block form") {
    100_000.times do
      logger.debug { "a message with #{array.inspect}" }
    end
  }
end

# Rehearsal -----------------------------------------------
# string form   0.910000   0.000000   0.910000 (  0.914628)
# block form    0.320000   0.000000   0.320000 (  0.322889)
# -------------------------------------- total: 1.230000sec
#
#                   user     system      total        real
# string form   0.900000   0.000000   0.900000 (  0.911639)
# block form    0.330000   0.000000   0.330000 (  0.329468)

Here we're just inspecting a 10 item array, but already we can see that the block version hasn't budged in terms of execution time, but the string version has crept up a little. Now lets take a look at some more extreme examples.

array = []
1.upto(1_000) {|i| array &lt;&lt; i}

Benchmark.bmbm do |x|
  x.report("string form") {
    100_000.times do
      logger.debug "a message with #{array.inspect}"
    end
  }
  x.report("block form") {
    100_000.times do
      logger.debug { "a message with #{array.inspect}" }
    end
  }
end

# Rehearsal -----------------------------------------------
# string form  65.790000   0.260000  66.050000 ( 68.107083)
# block form    0.330000   0.000000   0.330000 (  0.338018)
# ------------------------------------- total: 66.380000sec
#
#                   user     system      total        real
# string form  65.480000   0.250000  65.730000 ( 68.099213)
# block form    0.330000   0.000000   0.330000 (  0.350882)

We're now taking over 1 minute to loop over all those debug messages. The block version is almost 150 times quicker!

One more example just to drive my message home. This example is what drove me to write this post. I encountered some logging just like this in a map/reduce library. The library was attempting to log, albeit at the debug level, the entire entry data set for the map process. Even though I was running my evaluation script at the ERROR log level, it looked like the master process had locked up in a busy loop, but really the process was just trying to construct a string object that was going to be discarded in 3 lines anyways.

array = []
1.upto(1_000_000) {|i| array &lt;&lt; i}

Benchmark.bmbm do |x|
  x.report("string form") {
    100.times do
      logger.debug "a message with #{array.inspect}"
    end
  }
  x.report("block form") {
    100.times do
      logger.debug { "a message with #{array.inspect}" }
    end
  }
end

# Rehearsal -----------------------------------------------
# string form  94.360000   1.990000  96.350000 ( 97.137403)
# block form    0.000000   0.000000   0.000000 (  0.000299)
# ------------------------------------- total: 96.350000sec
#
#                   user     system      total        real
# string form  94.370000   2.080000  96.450000 ( 97.750037)
# block form    0.000000   0.000000   0.000000 (  0.000245)

I got impatient waiting for 100_000 iterations of this benchmark and dropped it to just 100.

So what's the moral of the story. You need to be aware of what you are logging. Keep in mind the amount of effort that is being spent in order to construct that lovely log message. I'll leave you with another sample program that hopefully showcases some other common logging tasks.

array = []
1.upto(10) {|i| array &lt;&lt; i}

attributes = {
  :id => 1,
  :title => "Super Simple Ruby Performance Tip",
  :published_at => Date.today,
  :tags => ["ruby", "performance", "tips"],
  :categories => ["Ruby"]
}

Benchmark.bmbm do |x|
  x.report("string form (array.first)") {
    100_000.times do
      logger.debug "a message with #{array.first}"
    end
  }
  x.report("string form (array.inspect)") {
    100_000.times do
      logger.debug "a message with #{array.inspect}"
    end
  }
  x.report("string form (attributes.inspect)") {
    100_000.times do
      logger.debug "a message with #{attributes.inspect}"
    end
  }
  x.report("block form (array.first)") {
    100_000.times do
      logger.debug { "a message with #{array.first}" }
    end
  }
  x.report("block form (array.inspect)") {
    100_000.times do
      logger.debug { "a message with #{array.inspect}" }
    end
  }
  x.report("block form (attributes.inspect)") {
    100_000.times do
      logger.debug { "a message with #{attributes.inspect}" }
    end
  }
end

# Rehearsal --------------------------------------------------------------------
# string form (array.first)          0.230000   0.000000   0.230000 (  0.239445)
# string form (array.inspect)        0.900000   0.010000   0.910000 (  0.918498)
# string form (attributes.inspect)   2.050000   0.000000   2.050000 (  2.056928)
# block form (array.first)           0.320000   0.010000   0.330000 (  0.330422)
# block form (array.inspect)         0.350000   0.000000   0.350000 (  0.347880)
# block form (attributes.inspect)    0.320000   0.000000   0.320000 (  0.326636)
# ----------------------------------------------------------- total: 4.190000sec
#
#                                        user     system      total        real
# string form (array.first)          0.240000   0.000000   0.240000 (  0.237537)
# string form (array.inspect)        0.900000   0.010000   0.910000 (  0.907226)
# string form (attributes.inspect)   2.040000   0.000000   2.040000 (  2.063976)
# block form (array.first)           0.320000   0.000000   0.320000 (  0.332216)
# block form (array.inspect)         0.330000   0.010000   0.340000 (  0.330169)
# block form (attributes.inspect)    0.330000   0.000000   0.330000 (  0.328436)

Full Program

A New Home

2015-03-05T09:56:00.517000Z

A long time ago, Dan and I decided we should split off and do our own personal blogs separately from twologic. We decided that twologic would simply aggregate data from both our personal blogs.

So here is my very own place. So as you can see, I’ve already brought my prior articles over to their new home and you can expect a few more articles out of me in the near future. I have been silent for far too long.

Now on Google Code

2015-03-05T09:56:00.873000Z

I have become increasingly busy (a.k.a. lazy), and no longer wish to maintain a darcs repository or setup some sort of issue tracking. So I have left that up to google. The project is now hosted over at http://code.google.com/p/inheritance/.

Over the next few days I will be updating the project page hosted here and moving more things over to google code. As of right now, the entire source tree is in revision control over there along with the latest 2.3 version download (contains the new Singleton stuff).

Feel free to start leaving tickets.

UPDATE: I got a little ahead of myself here. I accidently let some experimental code into the 2.3 release. If you have already downloaded the 2.3 release please upgrade to version 2.4.

For the curious, version 2.3 contained two versions of the new singleton method. In version 2.4 I moved what was labeled singleton2 into the singleton method and removed all references to singleton2.

Support for Singletons Added

2015-03-05T09:56:03.367000Z

I recently received an emailed from Nicholas Barthelemy of http://www.nbarthelemy.com regarding a little method he had written for creating Singletons with my inheritance library. Using Singletons in Javascript is something I do quite frequently, but I have always thought about them in the traditional Javascript sense (more on this later). I'd like to thank Nicholas for sending his email and for sparking my interest in adding support for the more classical style of Singleton.

Now without further ado, for your coding pleasure...I introduce Class.singleton!

But first a little background...

In its most basic form, a singleton in Javascript can be written quite simply using basic object notation.

var Singleton = {
  property: 'value',
  someMethod: function() {
  },
  otherMethod: function() {
  }
};

You can however get a little fancier and include some private data with your Singleton by taking advantage of closures.

var FancySingleton = (function() {

  // private variables and functions
  var secret = 'top secret';

  function decodeSecrets() {
    // ...
  }

  // return my public methods
  return {
    decrypt: function(code) {
      // public functions can access private
      // data and functions
      return decodeSecrets(code);
    }
  };
})();

All this is great and you've probably seen this style of Javascript in many many locations. However, if you come from a classical inheritance background you may have noticed that this style of code more resembles a namespace, or a Ruby module, or just simply as a Class with a pile of static methods and properties. In fact, this style of Javascript can be used and is used to namespace code in many libraries current available.

In a classical pattern sense, a Singleton is a class that has at least one static method you can use to obtain the only instance of that class (See: Singleton Pattern). None of the examples previously shown have this. Class.singleton brings this classical approach back to Javascript.

In its most basic form Class.singleton can be used just like Class.extend (Class.create for those Prototype-ists).

// define your App's singleton
var Application = Class.singleton({
  initialize: function() {
    // initializer function, called only once
    this.member = 'an instance member';
  },
  doSomething: function() {
    // ...
  }
});

So far, aside from using a different method, this looks nothing different from Class.extend. However, there are actually quite a few differences. If you tried to access any of the public methods you defined an error will be thrown by the Javascript engine.

// will not work, JS throws error
Application.doSomething();

If you were to inspect the Application object you might be a little worried since none of the methods you defined are actually attached to the Application object. In fact, it will contain only a single method getInstance. Just like you'd expect in the classical pattern, that getInstance function is used to obtain the only instance of Application class.

// get the instance
var app = Application.getInstance();

// will work now
app.doSomething();

I use a lazy loading technique to create the singleton instance the first time getInstance is called. This is when the initialize function that you defined will be called.

So what happens when you want to create a Singleton that inherits behavior from a base Singleton, or any Class for that matter. Well, that's just as simple as you would think. Again the parameter format matches Class.extend function.

// We need a better Application, that builds upon
// our existing Applications behaviours
var BetterApplication = Class.singleton(Application, {
  initialize: function() {
    // remember, I am called just once

    // call my parent constructor
    this.parent();

    // initialize more members
    this.newMember = 'yet another member';
  },

  // add more methods
  doMoreThings: function() {
    // ...
  }
});

var better = BetterApplication.getInstance();
app.doSomething();
app.doMoreThings();

The above code will create a BetterApplication singleton object that inherits functionality from Application.

Long awaited project page arrives

2015-03-05T09:56:06.277000Z

Well, I finally got rid of my laziness. Well, at least for most of the weekend. The lame Inheritance.js project page has finally been updated. There is now some real content there, not just some lame page saying there is "more to come in just a little while". Head on over to pick up the javascript file and see the latest explanation of what Inheritance.js can do for you.

What''s in store for the future? Well, I''ve decided that I want to devote a portion of my free time, no matter how little there is, to working on open source software. I feel that I have a lot more I could contribute to the community of developers out there. I have my eyes on a few specific projects that I would like to get involved with, but we shall see if that works out. In terms of what the future holds for Inheritance.js, well I plan to get some sort of issue tracking system up in place. I don''t expect there to be many issues, but inevitably there will be. An issue tracking system would also be a great place for people to post suggestions for improvements and other ideas regarding the enhancement of this library. So stay tuned over the next little while for another update in that regard.

As a side note, I have submitted Inheritance.js as one of Prototype''s "best built-with-Prototype third-party libraries". With any luck, hopefully you''ll see Inheritance.js on the official Prototype list when it comes out.

Prototype Patch Re-submitted

2015-03-05T09:56:06.644000Z

Well I finally got off my high horse and made some time to build out a collection of unit tests for my inheritance library. I took the latest code along will all the newly written unit tests and bundled them into a nice patch for prototype. I re-attached them to my original patch so hopefully it will be included in a future version.

Now that I have your attention, I thought I'd spend a bit of time to discuss some code I discovered while building out this latest set of unit tests. While looking through the scriptaculous unit testing suite I found a neat little entry at the bottom of unittest.js. I'm not sure when it was added, so if this is really old news I apologize for being behind the times.

At the bottom of unittest.js there is an experimental BDD implementation in the works. This is neat, I've seen BDD (Behavior Driven Development) frameworks in Java as well as Ruby and now there's an implementation for JavaScript.

So what does all this mean? Well, it means you can write your unit tests like a product specification. Using an example from RSpec, we can write the following test suite that reads like a specification:

var stack;

Test.context("An empty stack", {

  setup: function() {
    stack = new Stack();
  },

  "should be empty": function() {
    assertReturnsTrue('empty', stack)
  },

  "should no longer be empty after 'push'": function(){
    stack.push("anything");
    assertReturnsFalse('empty', stack)
  },

  "should complain when sent 'peek'": function(){
    assertRaise('StackUnderflowError',
      function(){stack.peek()});
  },

  "should complain when sent 'pop'": function(){
    assertRaise('StackUnderflowError',
      function(){stack.pop()});
  }

});

Now, in true BDD fashion, we should actually write our Stack implementation. Our test suite not only acts like the specification but allows us to programatically ensure that the Stack implementation we do end up writing meets that specification as well.

Updated OO Library

2015-03-05T09:56:07.029000Z

It has been a while since I last posted and I just wanted to make a quick announcement. Version 2.2 of my Ruby style OO library is now ready for public consumption. It has been sitting around in my darks repository for a good little while now. This new version is functionally identical to the version I last blogged about. The only change I have made is a slight alteration based on some feedback I received from Justin Palmer of EncyteMedia.

In this new version I renamed Class.create to Class.extend, but before you go off on a frantic search and replace. Don't worry, because even though the Class.create method is now deprecated, it won’t disappear for a little while.

So what prompted me to make this change?

Well, Justin pointed a subtle difference between my syntax and the syntax used by Dean Edward's Base.js library.

From Dean Edward's library:

var Square = Shape.extend({ ...
as apposed to my library.

var Square = Class.create(Shape, { ...

In Justin's opinion the syntax of the first version is much more concise than the syntax found in my version. I concur, however in order to achieve that kind of syntax Shape has to have the method extend injected into it's definition by the OO library. This breaks one of the additional set of rules I had defined for my own library. In an effort to make the syntax of my own library a bit more concise I moved the core functionality into Class.extend as seen here.

var Square = Class.extend(Shape, { ...

It's still not nearly as concise, but I feel it is a good compromise. At least the verb extend makes more sense than create in this particular use.

One finally word of warning for those intending to mix my library with Prototype. Even though Class.extend is now the preferred method for creating and extending your own Classes, you are still required to include my library after Prototype in your own work.

Once again head on over to the project page to grab the javascript file.

Javascript OO Ruby Style

2015-03-05T09:56:07.541000Z

This is a follow up post regarding the OO inheritance javascript library I blogged about earlier. I planned on submitting my original work as a patch to Prototype. Before submitting my patch at the rails development site I checked out the competition. I found a couple OO implementations already in contention for the next major version of Prototype. For the curious, both of them are mentioned on Sam Stephenson's weblog.

I spent some time looking over both solutions. Each one tried and did a very good job of implementing OO features, but they both had parts I didn't like. One author thought it would be neat to add support for private methods. This is neat, but I don't think javascript really needs this. People have been writing javascript for years without it and every attempt I've seen to add it to the language has seemed kind of hackish, well at least to me. You'll find my biggest beef with both libraries when you inspect an instance of one of your classes. You'll find a couple added methods and properties that the library injects so that it can do it's job. In fact even my previous OO library was guilty of this, something that bugged me to no end.

So I sat down one evening and rewrote the core of my own library to meet all my demands and expectations. I am proud to say that the new library is much smaller, sleeker and generally just feels better than the first. I also added some neat new features along the way.

Visit the project page for details on how to get the library.

Just like Dean Edwards, I want an OO library that solves a number of problems.
For convenience, here is Dean's list.

http://dean.edwards.name/weblog/2006/03/

I want to easily create classes without theMyClass.prototype cruft
I want method overriding with intuitive access to the overridden method (like Java’s super)
I want to avoid calling a class’ constructor function during the prototyping phase
I want to easily add static (class) properties and methods
I want to achieve the above without resorting to global functions to build prototype chains
I want to achieve the above without affectingObject.prototype

However, I have a few additions.

I want a more Ruby like feel to creating and working with Objects.
I want to achieve all of the above without adding additional baggage to final object.
I want to achieve all of the above while maintaining backward compatibility with Prototype.

So what's so new and great with my OO library? Well, since creating the first version I've learned a few neat tricks to help achieve my goals. First lets talk about mixins. Previously you had to define your mixins on a separate line
after your class definition.

Debug = {
  log: function(msg) {
    alert(msg);
  }
};

Employee = Class.create({
  initialize: function() {
    this.log("In the Employee constructor!");
  }
});
Class.mixin(Employee.prototype, Debug);

Client = Class.create({
  initialize: function() {
    this.log("In the Client constructor!");
  }
});
Class.mixin(Client.prototype, Debug);

Well I've added a bit of syntax sugar that in turn adds more Ruby flavor. It’s now possible to statically define an objects mixins within the class definition.

Comparable = {
  // define methods...
};
Debug = {
  // define methods...
};
Employee = Class.create({
  // define a single mixin
  include: Debug,
  initialize: function() {
    // ...
  }
});
Client = Class.create({
  // define an array of mixins
  include: [Debug, Comparable],
  initialize: function() {
    // ...
  }
});

Each element given to the include property will have all of it's methods mixed into the objects' s definition. All standard rules for Ruby mixins are followed and apply when added this way. Also, it's worth noting that the include property will be removed from the object's definition. This way you won't see it when you inspect instances of your class.

The second improvement is in the this.parent() method. It's now smart enough to recognize what method it is being used inside of, so you no longer have to explicitly tell it what method to call.

Manager = Class.create(Employee, {
  initialize: function(name, dept, title) {
    this.parent(name, dept);
    this.title = title;
  },
  doWork: function() {
    this.parent();
  }
});

If you have defined a property or method using the same name, it will overwritten. It's also important to note that the 'this.parent()' method is only available inside a method definition. Doing something like the following will result in a javascript error.

var joe = new Manager();
joe.parent();

The last visible difference between this version and my previous is that I no longer force properties into the generated objects. This is best demonstrated with an example.

Debug = {
  log: function(msg) {
    document.writeln(msg);
  }
}

Employee = Class.create({
  initialize: function(name, dept) {
    <a href="http://this.name">this.name</a> = name;
    this.dept = dept;
  },
  doWork: function() {
    return <a href="http://this.name">this.name</a> + " is now working...";
  }
});

Manager = Class.create(Employee, {
  include: Debug,
  initialize: function(name, dept, title) {
    this.parent(name, dept);
    this.title = title;
  },
  doWork: function() {
    this.log(this.parent() + "at managing the employees.");
  }
});

var joe = new Manager("Joe", "Sales", "Sales Manager");
joe.doWork()

var out = "";
for (var p in joe) {
  out += p + ": " + joe[p] + ",\\n"
}
out = out.substring(0, out.length - 2);
Debug.log("Manager {\\n" + out + "\\n}");

Outputs:

Joe is now working...at managing the employees.
Manager {
  name: Joe,
  dept: Sales,
  title: Sales Manager,
  initialize: function (name, dept, title) {
    this.parent(name, dept);
    this.title = title;
  },
  doWork: function () {
    this.log(this.parent() + "at managing the employees.");
  },
  log: function (msg) {
    document.writeln(msg);
  }
}

As you can see the for (var p in joe) construct returns exactly what you defined. There are no extra methods or properties visibly added to you object to make any of this work. You can also see that the log method was mixed into the class definition and the include property no longer exists.

Visit the project page for details on how to get the library.

Object Inheritance with Javascript

2015-03-05T09:56:07.759000Z

Recently I've been spending a lot of my time experimenting with and writing web-applications powered by a fair bit of Javascript. I've toyed with a couple of the new big hitters in the world of Javascript; namely Prototype and MochiKit. If you haven't heard of either library, I encourage you to take a peak and explore them both. They provide a large set of useful functions and features that will help to save you time when writing your own Javascript. I'm not about to discuss which one is better than the other, nor am I going to do a feature comparison between both libraries. There are plenty of articles and blog posts that already do just that. Instead I am going to focus on something else; something that neither of those two libraries really help with. I am going to focus on writing Object-Oriented Javascript.

There are a lot of pitfalls and not so attractive code that is needed in order to accomplish certain OO tasks in Javascript. I've written a little library that I think helps to simplify all this. However, before I get into the details of my own work, I think a little background is in order. Of course, you could skip right down to it if you are already familiar with the pitfalls of writing OO in Javascript.

A little background

As many readers may already know Javascript is a prototype-based language3. It is possible to define your own objects, however the syntax for doing so is somewhat clumsy. I won't go into all the details on how to create objects since you can read them for yourself in the Core Javascript Guide, but here's a brief rundown.

Traditionally the following code would define a constructor function for our Employee object.

Employee = function() {
  <a href="http://this.name">this.name</a> = '';
  this.dept = "general";

};

Methods can be added to our Employee object with the following:

Employee.prototype.doWork = function() {
  return "Employee is working...";
};

Employee.prototype.takeBreak = function() {
  return "Employee is slacking off...";
};

The above code is quite verbose and cumbersome. Alternatively, the following syntax will achieve the same effect.

Employee.prototype = {
  doWork: function() {
    return "Employee is working...";
  },
  takeBreak: function() {
    return "Employee is slacking off...";
  }
};

This is a bit cleaner, however defining your object still requires two independent chunks of code. Also, the situation just gets even worse when you try and create a hierarchy of objects.

Manager = function() {
  this.reports = [];
};
Manager.prototype = new Employee();

Here we have defined Manager to be a subclass of Employee. However, now your only option to add methods to our Manager object is to use the traditional way.

Manager.prototype.manage = function() {
  return "Manager is now micro-managing...";
};

The following will not work because we would loose our object hierarchy.

Manager.prototype = {
  manage: function() {
    return "Manager is now micro-managing...";
  }
};

If you are using either of the Prototype or MochiKit libraries you can however cheat a little here and use a handy feature that is present in both libraries.

Using Prototype:

Manager.prototype = Object.extend(new Employee(), {
  manage: function() {
    return "Manager is now micro-managing...";
  }
});

Using MochiKit:

Manager.prototype = MochiKit.Base.update(new Employee(), {
  manage: function() {
    return "Manager is now micro-managing...";
  }
});

Object.extend(..) and MochiKit.Base.update(..) both perform the same task of mutating and returning the first parameter replacing all of it's key:value pairs with those from the second parameter. This allows you to create an object hierarchy and keep using the cleaner syntax for defining your Objects methods.

All of this works great until you want to call a method on a parent class. There is no nice way of doing this natively in Javascript. Instead, you have use some rather explicit and gross looking code the uses either Function.apply or Function.call.

Manager.prototype.doWork = function() {
  return Employee.prototype.doWork.call(this) +
    "managing the rest of the employees.";
};

This bit of code isn't very nice for a number of reasons. The one reason I dislike the most about this bit of code is that it doesn't make life easy if you ever come back and alter your work. Lets say your hierarchy changes and Managers are no longer Employees, instead they are Owners. Now you have to go searching through all your code looking for all the cases where you calledEmployee.prototype.someFunc.call(..).

There isn't really a nice way around this without adding some additional features to the language. I spent some time the other evening trying to piece together a nice extension that will make the syntax for writing Objects cleaner and simpler, while still playing nicely with those big hitting libraries. The complete JS is available for download at the bottom of this post. The next few examples will demonstrate how to use my little extension.

The Good Stuff

I've created a Class object that mimics the Class object found in the Prototype library. If you already use Prototype, your old code should continue to work without any side effects. At the core of my extension is the Class.create() method.

In order to create a new Object you can use the following syntax (if you use the Prototype library already, then this will be familiar).

Employee = Class.create();
Employee.prototype = {
  initialize: function() {
    <a href="http://this.name">this.name</a> = "";
    this.dept = "general";
  },
  doWork: function() {
    return "Employee is working...";
  },
  takeBreak: function() {
    return "Employee is slacking off...";
  }

};

So what is this doing? In this case Class.create() creates a constructor function for us. The created constructor will call the initialize method on Object creation. So in essence we can treat initialize as our constructor. So far this functionally the same as the Class.create() method found in the Prototype Library, however thats not all I have done. I took this idea one step further and combined both the constructor creation and the prototype definition in one convenient call.

Employee = Class.create({
  initialize: function() {
    <a href="http://this.name">this.name</a> = "";
    this.dept = "general";
  },
  doWork: function() {
    return "Employee is working...";
  },
  takeBreak: function() {
    return "Employee is slacking off...";
  }
});

The above code will create the Employee object we created earlier. You no longer have to separate your Object definition into two pieces. Its all done at the same time.

But wait, there's more! I took it another step further. What happens when you want to create an object hierarchy?Class.create() can do that too!

Manager = Class.create(Employee, {
  manage: function() {
    return "Manager is now micro-managing...";
  }
});

So now using a very simple syntax we've created our Manager Object, that inherits functionality from Employee and we've defined the manage method that only Managers have.

Well what about that problem of calling methods defined in the parent class? Well if you create your Objects using the above Class.create() syntax, then you will find a special helper method already defined in each of your Objects.

Manager = Class.create(Employee, {
  //...
  doWork: function() {
    this.parent('doWork');
  }
});

The parent method is defined internally when you create an Object using Class.create(). The parent method takes two parameters, the first is the method to call and the second optional parameter is an array of arguments to pass to that method.

  this.parent('doWork');
  this.parent('doWork', [param1, param2, ...]);

The parent method is inspired from the way messaging works in Objective-C and borrows some naming conventions from Ruby. It will look in the parent class for the given method. If it cannot find it there it will continue the search upwards in every parent class until it reaches the top of the chain. If at this point it still cannot find an implementation of that method it calls a specialmethod_missing method, which you can override to do something special if you so wish. The defaultmethod_missing implementation just throws an error.

Mixins

The last thing worth mentioning is the Class.mixin() method, which is identical to Prototype's Object.extend() method or the MochiKit.Base.update() function. I believe mixin is a better name since, you are essentially mixing in the key:value pairs from another object. You can use this method to mixin common functionality. This works very similarly to mixin support you find in other languages such as Ruby.

Debug = {
  log: function(msg) {
    alert(msg);
  }
};

Employee = Class.create({
  initialize: function() {
    this.log("In the Employee constructor!");
  }
});
Class.mixin(Employee.prototype, Debug);

Client = Class.create({
  initialize: function() {
    this.log("In the Client constructor!");
  }
});
Class.mixin(Client.prototype, Debug);

Now both Employee and Client objects have an identical log method.

var e = new Employee();
// alert with message "In the Employee constructor!" will be seen

var c = new Client();
// another alert with message "In the Client constructor!" will be seen

I have included class.js into a project I have on the go write now, and I plan on incorporating class.js into several other projects that have been put on the back-burner but should come back to life soon. The source is available via darcs, and more documentation will start appearing soon as well.

I have a few additional ideas for improving upon this extension, and there is still one final gotcha that needs to be overcome. I will leave that for another post however, since this one is already long enough.

And Finally, The Goods

Project page and just the inheritance.js file.

code repository: https://github.com/voidlock/inheritance