Why I'm using Coffeescript... For Now

To put it mildly, JavaScript has some idiosyncrasies. I've enjoyed manipulating, and exploiting some of JavaScript's more interesting aspects. However, it's uniqueness can cause confusion. It is perfectly fine to those with experience with JavaScript, but they often trip up even experience programmers that aren't well versed in the language.

Concerns about debugging

One major advantage of JavaScript development is how well debugging is integrated. Chrome and now Firefox debugging is pretty awesome. The only comparable interfaces I've used are Eclipse and XCode, and Chrome preforms better than either of these.
Initially I was concerned that the change in syntax and line numbers would make debugging difficult. Put simply, this turns out to this is much less of an issue than I anticipated. It is trivial to identify corresponding CoffeeScript code working backward from compiled JavaScript.

Class creation

It starts with simple class creation. In JavaScript there isn't anything to distinguish a Class from any other named function.

var MyClass = function(){};

That is, until you add methods to it.

MyClass.prototype.foo = function(){};

This is just weird.
CoffeeScript makes it a little more clear what is a class.

class MyClass   
    foo: ->

Which this is this

Here's a common scenario. I want to bind an instance method of an object to listen to an event (Mouse Click, AJAX response whatever). In java script I have to store this in a local variable so that I can use it later. Looks something like this.

var MyClass = function(){
    var t = this;
    $("a.bindo").click(function(){
        t.onClick();
    })
}

MyClass.prototype.onClick = function(){
    console.log("This is me", this);
}

I've used that pattern hundreds of time. It is useful, but again confusing to someone new to the language. The CoffeeScript version, by contrast, is succinct.

class MyClass   
    constructor: ->
        $("a.bindo").click @onClick

    onClick: => 
        console.log("This is me", @)

It is true that the developer has to understand on a conceptual level what is happening with the bind event, but I find that a simple character difference is more readily accessible and apparent than the JavaScript pattern.

Inheritance

CoffeeScript inheritance murders JavaScript inheritance. I have an older post on JavaScript prototype inheritance. It works (kinda), but again is unfamiliar to people coming from other languages.
CoffeeScript inheritance is easy, and offers something I've not seen cleanly executed in raw JavaScript. The super keyword in CoffeeScript called the super
in JavaScript to call the parent method it looks something like this.

var MyClass = function(){
    ParentClassName.call(this, arguments)
}

Now I think call and apply are super dope, but most of the time I would prefer to never touch them. Now the CoffeeScript equivalent

class MyClass extends ParentClassName
    constructor: ->
        super

That's is way easier, and way less likely to cause hard to track down bugs.

Integration with Ruby stack

In the 12 months we moved over to a Ruby stack after spending a long neolithic era using PHP. It is very easy to integrate CoffeeScript into an application using several Ruby frameworks including: Rails, Sinatra, and Serve. Not having to do any extra work to integrate CoffeeScript was a huge plus!

Dart

Dart looks awesome and I'll be following its progress, once it is supported by a couple major browsers (not just compiled to JavaScript), I'll be more than happy to give it a serious look. Strong typing and isolates are enough reason for serious consideration.

Conclusion

CoffeeScript isn't perfect. And I'm looking forward to new languages to come out for the browser platform. But the bottom line is productivity. And right now, for me and our team, CoffeeScript has a few key features that make web client dev less of a grind, while allowing us to leverage our JavaScript knowledge.

Javascript OOP - Multiple Inheritance

Multiple inheritance is a behavior when a single class extends the functionality of multiple parent classes. For example, an alarm-clock has the properties of both a clock and an alarm. The desired situation is that the parent classes handle the distinct behaviors without needing to know about each other. For an alarm-clock, this means that the clock class will track time, the alarm class would make an alarm action, and the alarm-clock class would allow different events to be set at specific times of the clock.

Many OOP languages support multiple inheritance either directly (C++) or through some other mechanism (Java Interfaces, Objective-C Protocols). How can this be implement in JavaScript. Enter jQuery.

jQuery has this baller function, $.extend. It receives n arguments ( $.extend(arg0, arg1, …., argN); ) and all the members of argN are copied to arg(N-1), then from arg(N-1) to arg(N-2), and so on down the line. This is perfect for creating options for jQuery parameters. However, it can also be used to implement Multiple Inheritance for javascript objects.

Lets check out a very simple, snarky alarm clock.

//create parent Alarm
Alarm = function(){};
//with one instance method
Alarm.prototype.ring = function(){
     console.log("AAAAAHHHHHHHH");
}

//create parent Clock
Clock = function(){};
//with one instance method
Clock.prototype.time = function(){
     console.log("is an illusion");
}

//create child
AlarmClock = function(){};
//inherit from A and B
AlarmClock.prototype = $.extend(new Clock(), new Alarm()); // BOOM!

c = new AlarmClock();
c.ring();//AAAAAHHHHHHHH
c.time();//is an illusion

Pretty cool. However, multiple inheritance presents situations that single inheritance doesn't. What happens if parent classes contain identically named methods? In $.extend the right hand parameter overrides the one to its left. So, if ClassA and ClassB have identically named methods, then ClassB's will override ClassA's.

Lets see this in action.

//create parent with cry
Human = function(){};
Human.prototype.cry = function(){
     console.log("OUCH!!!");
}

//create another parent, also with cry
SpaceMarine = function(){};
SpaceMarine.prototype.cry = function(){
     console.log("FOR THE EMPEROR!");
};

//inherit from both parents
Character = function(){};
Character.prototype = $.extend(new Human(), new SpaceMarine()); // BOOM!
c = new Character();
c. cry(); //FOR THE EMPEROR!
//cry is inherited from SpaceMarine

Multiple inheritance also evokes an interesting question for object type. What is the object type of ClassC? In this case only the leftmost parent class passes on its type.

ClassC = function(){};
ClassC.prototype = $.extend(new ClassA(), new ClassB()); // BOOM!
var c = new ClassC();
console.log(c instanceof ClassA); //true
console.log(c instanceof ClassB); //false

This technique requires some function to duplicate properties and methods from object to object. I use jQuery.extend, because I use jQuery it on most projects, but there could be alternatives out there, and it would be simple to create a  rudimentary replacement.

Multiple inheritance is especially useful with protocols. For example, a single class to provide data for and respond to interaction with a datalist, ala UIKit's UITableViewDataSource and UITableViewDelegate. To allow a single object to perform two distinct tasks, some form of multiple inheritance must be used.

What I learned from THREE.js: calling parent methods

Three.js is awesome, it simplifies working with WebGL, and is a great source for JavaScript ideas. This article presents another idea I came across while working THREE.js source; applying a parent class' constructor to an inheriting class. To do this the parent constructor is invoked using apply or call.

var ClassA = function(){};

//ClassB inherits ClassA
var ClassB = function(){
    ClassA.call(this); //run parent constructor on this object
};
ClassB.prototype = new ClassA(); //inherit parent methods

The example above does call the parent constructor, but doesn't accomplish anything. Instance methods and properties are added to the prototype on the last line of the block. Calling the parent constructor is only useful when there are parameters. A simple example is extending DataModel object that manipulate and hold information pulled from a database.

//assume data has been converted to a javascript object
var DataModel = function(data){
    data = data || {}; //make sure data is a valid object
    this.id = data.id || ""; //stores id on the instance
};

//person inherits from data model
var Person = function(data){
    DataModel.call(this, data); //get a valid id

    data = data || {}; //make sure data is a valid object
    this.firstName = data.firstName || ""; //stores id on the instance
    this.lastName = data.lastName || ""; //stores id on the instance
}
Person.prototype = new DataModel();

Now any class that extends DataModel will have some defined value for id. Similarly an extension of Person would have a defined value for firstName and lastName.

You can take this concept even further. It can be used when overriding inherited methods as well. Note: this will not work as expected if using THREE.js' technique of defining instance methods as explained in the preceding THREE.js article.

In this next block, the DataModel and Person classes implement a toObject function, that returns the instance property values. The DataModel handles the the id property, while the Person handles the first and lastName properties.

//returns the 
DataModel.prototype.toObj = function(){
    var obj;
    obj.id = this.id;
    return obj;
}

//overrides DataModel toObj.
Person.prototype.toObj = function(){
    var obj = DataModel.prototype.call(this); //get object with id
    obj.firstName = this.firstName;
    obj.lastName = this.lastName;
    return obj;
}

In retrospect, this idea seems obvious. After all, this article demonstrates how to use call or apply to implement private methods, and the idea presented in this post simply uses the same concept on parent methods.

What I learned from THREE.js: new way to encapsulate

Recently I've had the oportunity to work extensively with THREE.js, a WebGL framework primarily authored by Mr. Doob. This library simplifies the use of the powerful WebGL graphics engine. Not only is this library an excellent resource for WebGL, it also introduced me to some new techniques for JavaScript encapsulation and inheritance. This article presents a technique for simplifying method definition syntax.

Restructuring Class Implementation

The common method for adding methods to an object is to add the method names directly to the prototype.

var ClassName = function(){};
ClassName.prototype.methodName = function(){};

This works, but is a little verbose, and requires a lot of find/replace when overriding inherited methods. The clases in THREE.js avoid this repetition by defining instance methods during object construction. It looks like this.

var ClassName = function(){
        this.methodName = function(){};
};

The benefits are twofold. The syntax for method definition and overriding has been simplified. Also, Using the constructor for encapsulation obviates the use of closures to obfuscate private methods (as demonstrated in this previous post), further simplifying syntax.

Consider the following two classes.

/*
Class: ClassA
*/
var ClassA = function () {
        //add functions to object inside of constructor, simpler syntax
        this.foo = function () {
            console.log("parent foo");
            privateFoo.call(this);
        };
        //private methods also defined inside constructor
        function privateFoo() {
            console.log("parent private foo");
        }
    };

/*
Class: classB
inherits from classA.
*/
var ClassB = function () {
        this.foo = function () {
            console.log("child foo");
            ClassB.prototype.foo.call(this); //calling parent method
        };

        this.bar = function () {
            console.log("child bar");
        };
    };
ClassB.prototype = new ClassA();

var b = new ClassB();
b.bar(); //child bar
b.foo(); //child foo, parent foo, parent private foo

This is significantly more concise, and worth investigating further.

Issues

An obvious fault is that to call the parent method you have to access the child's prototype. This is conceptually confusing and a regression from the previously outlined method, where the parent prototype would be accessed (ie. ClassA.foo.call(this) ).

There is also a potential performance issue. It is possible that creating a new definition of instance methods at runtime will have an adverse affect on either memory footprint or speed. This will have to be tested.

Conclusion

It is to early to tell if I will start using this particular encapsulation scheme. The parent method mapping is a little strange, and the performance issue is something I'll have to investigate further. I will post any findings.

JavaScript OOP - Extending Objects

An interesting concept in Objective-C is the Category. Categories allow developers to add methods to existing Classes, even if the source code is unavailable. This can be done in JavaScript by adding functions to an existing class' prototype. This article demonstrates how to add methods to Array.

/*
  * Function: removeItem
  *  This function removes all occurrences of this item
  *  
  * Parameter:
  *  item - The item being removed. Can be primitive or object. If object must be same instance.
  */
 Array.prototype.removeItem = function(item){
  var length = this.length, i;
  
  for(i=0; i < length; i++){
   var member = this.pop();
   
   if(member !== item){
    this.unshift(member);
   }
  }
 };

Now items can be removed from any array just by calling that method.

//Remove Numbers
var numberArr = [1,2,3,2];
console.log(numberArr); // 1 2 3 2
numberArr.removeItem(2);
console.log(numberArr); // 1 3

//Remove string
var numberArr = ["1","2","3","2"];
console.log(numberArr); // "1" "2" "3" "2"
numberArr.removeItem("2");
console.log(numberArr); // "1" "3"

How cool is that? Even objects defined with native code can be extended to increase their utility and ease of use.

JavaScript OOP - type checking and inheritance

When working on large project, likely requiring a large OOP structure for coherence, it is important to have consistent types. If you're expecting an object to have this property or that method, it should be there. In fact a major benefit of working with a statically typed language such as Java or Objective-C, is that variable type is determined at compile time, is that variable type is strictly enforced. For example, when a function receives a parameter that is of incorrect type, a compile time warning or error can be generated. By contrast, JavaScript is dynamically typed (determined at runtime). This can lead to type runtime errors that can be difficult to track down.

To combat this, the instanceof operator can be used to enforce type. instanceof B evaluates to true when a is an instance of B, simple enough. What is really interesting is that when using the inheritance method outlined previously instanceof can also be used to determine if an object inherits from a prototype as well as implementing one.

//Create prototypes
var classA = function(){};
var classB = function(){};
classB.prototype = new classA(); //classB inherits from classA

var a = new classA();
var b = new classB();

//a is not identified as an instance of classB,   
console.log(a instanceof classA); //true
console.log(a instanceof classB); //false

//b is identified as an instance of classA. 
console.log(b instanceof classB); //true
console.log(b instanceof classA); //true

Here is a quick example of how to use this in a function to enforce type safety.

//function that requires classB
function needsClassB(b){
  if(!(b instanceof classB)){
    throw("needsClassB passed invalid argument: "+b);
  }

  console.log("we can do super awesome classB only stuff!");
}

//objects
var a = new classA();
var b = new classB();

needsClassB(b); //we can do super awesome classB only stuff!
needsClassB(a); //throws error

This lacks the elegance of defining types in the method definition, as you would in Java or Objective-C, but JavaScript often requires compromise. And this technique provides as least a measure of certainty that the arguments are going to be what is expected.

JavaScript OOP - Prototyping Encapsulation and Inheritance

JavaScript is a really cool language. Its flexibility allows a clever developer to achieve some incredible things. However, this unbridled freedom comes at a price. It is the responsibility of the programmer to impose order to this chaotic environment. A good first step in this daunting challenge is to implement some useful object oriented concepts. This post demonstrates how to implement encapsulation and inheritance for javascript prototype classes.

Encapsulation

The fundamental goal for encapsulation is to control what variables/functions are available for external access. The mechanism for doing this in JavaScript is a closure. By wrapping the class definition in a closure it is possible to have private functions accesible only this class, since objects outside of the closure won't be in the same scope.

(function(){
 
 //constructor
 window.JSObject = function(){
  this.publicInstanceVar1 = 1
 }; 

 // public function
 JSObject.prototype.foo = function(){
  privateFunction.apply(this); //call private function
 }; 

 //private function
 function bar(){} 

 var privateClassVar1 = "1"

}());

The constructor must be attached to the window, or declared outside of the closure, otherwise it will not be accessible externally. The public method is added to the object prototype. The private method is a function declared inside of the closure and must be called using apply or call to maintain the consistency the this variable.

Inheritance

Inheritance for a prototype object is very simple. Assigning a new parent object to the prototype of the inheriting object will do the trick.

(function(){
 window.Child = function(){};
 Child.prototype = new Parent();
}());

The instance variables and public functions are now available in the child class. The private methods and private class variables will not be inherited.

Click Here to see a demo.

jQuery OOP - Inheritance

In my last post I outlined how to achieve some encapsulation behaviors within a jQuery plugin framework. This time I'll be taking a look at inheritance. Specifically I want to able to inherit or override members of one class for use in an inheriting class.

The full objects and examples can be found here.

Super Class

To facilitate inheritance one change had to be made to the super class. The plugin needs a a function (hasFunction) that determines if the plugin responds to a given function.

(function($) {
        //public functions
        var methods = {
                init : function(options) {
                        var defaults = {};
                        $.extend(this, defaults, options);
                        ...
                        return this
                },
                //function to check if plugin responds to function
                hasFunction : function(functionName){
                        return (methods[functionName] !== undefined);
                }
        };                
        $.fn.objectA = function(method) {
                if (methods[method]) {
                        return methods[method].apply(this, 
                               Array.prototype.slice.call(arguments, 1));
                } else if (typeof method === 'object' || !method) {
                        return methods.init.apply(this, arguments);
                } else {
                        $.error('Method ' + method + ' does not exist on jQuery.');
                }
        };
})(jQuery);

Sub Class

Some more work has to be done on the sub class. There is the hasFunction method again, but now that function has to check its parent as well.

Also, In the initialization block two extra changes have to be made. After checking if this plugin responds to a method name, the plugin must check to see if the parent responds, and if so, call the method on the parent plugin. If the plugin is initializing, the parent must be initialized with the same parameters,

(function($) {
        //public functions
        var methods = {
                init : function(options) {
                        var defaults = {};
                        $.extend(this, defaults, options);
                        this.objectBInstance = "Intance B";
                        
                        return this;
                },
                //function to check if plugin responds to function
                hasFunction : function(functionName){
                    //does this or the super class respond to this?
                    return (methods[functionName] !== undefined || this.$super(functionName));
                }
        };        
        /*
                Initialization
        */        
        $.fn.objectB = function(method) {
                if (methods[method]) { //check this class for the method
                        return methods[method].apply(this, 
                                Array.prototype.slice.call(arguments, 1));
                } else if(this.objectA("hasFunction", method)){ //next check the parent
                        //use apply without changing to maintain args
                        return this.objectA.apply(this, arguments);
                }else if (typeof method === 'object' || !method) {//try to init
                        //inherit first inheritance method
                        this.objectA.apply(this, arguments); //inherit from objectA
                        this.$super = this.objectA; //objectA is $super                        
                        return methods.init.apply(this, arguments); //initialize this 
                } else {//if missing from parent/self and not init err out
                        $.error('Method ' + method + ' does not exist on jQuery.');
                }
        };
})(jQuery);

Summary
The inheritance method I outlined above enables public methods and instance variables can be inherited from the super class. In the future I would like to extend this to facilitate multiple inheritance.