Typical Noise

Alex Arnell

Coffee fueled terminal junky. A Software Developer with a strong passion for good software design and an unquenchable thirst for learning.

Prototype Patch Re-submitted

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(){
    assertReturnsFalse('empty', stack)

  "should complain when sent 'peek'": function(){

  "should complain when sent 'pop'": function(){


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

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.