Prototypal Inheritance in Javascript - Template Method meets Strategy

I have been reading some of the papers on Self, a programming environment that models computation exclusively in terms of objects. However unlike the classical object-oriented approach, Self is a classless language, where everything is an object. An object has slots - each slot has a name and a value. The slot name is always a String, while the value can be any other Self object. The slot can point to methods as well, consisting of code. A special designated slot points to the parent object in the hierarchy. Hence each object is consistently designed for extensibility through inheritance. But since we don't have class structures, everything is dynamic and runtime. Objects interact through messages - when an object receives a message, it looks up into its slot for a match. If the matching message is not found, the search continues up the chain through successive parent pointers, till the root is reached.

Prototype based languages offer a different way of implementing objects, and hence require a different thinking for structuring your programs. They make you think more in terms of messages that your objects will receive, and how the messages get propagated up the inheritance chain.

Javascript follows an almost identical architecture, where the hierarchies of objects are constructed through prototypes. This post is not about Self or, for that matter, about the Javascript language. Some time back I had blogged about how the Template Method design pattern gets subsumed into higher order functions and closures when implemented using functional programming languages.

In a class based language, template method pattern is implemented in terms of inheritance, which makes the structure of the pattern static and makes the derivatives of the hierarchy statically coupled to the base abstraction. Closures liberate the pattern structure from this compile time coupling and make it dynamic. But once we take off the class inheritance part and use higher order functions to plug in the variable parts of the algorithm, what we end up with closely matches the Strategy pattern. Have a look at James Iry's insightful comments in my earlier post.

James also hinted at another level of subsumption which is more interesting - the case of the two patterns implemented in a prototype based language like Javascript. Here is how it looks ..

// the template function at the base object
// defines the generic flow
// uses hooks to be plugged in by derived objects

var processor = {
  process: function() {
    this.doInit();
    this.doProcess();
    this.doEnd();
    return true;
  }
};


We construct another object that inherits from the base object. The function beget is the one that Douglas Crockford defines as a helper to create a new object using another object as the prototype.

if (typeof Object.beget !== 'function') {
  Object.beget = function(o) {
    var F = function() {};
    F.prototype = o;
    return new F();
  };
}

var my_processor  = Object.beget(processor);


The new object now implements the variable parts of the algorithm.

my_processor.doInit = function() {
  //..
};
my_processor.doProcess = function() {
  //..
};
my_processor.doEnd = function() {
  //..
};


and we invoke the function from the base object ..

my_processor.process();

If we need to define another specialization of the algorithm that only has to override a single variable part, we do it likewise by supplying the object my_processor as the prototype ..

var your_processor= Object.beget(my_processor);
your_processor.doEnd = function() {
  //.. another specialization
};

your_processor.process();


So what we get is a dynamic version of the Template Method pattern with no static coupling - thanks to prototypal inheritance of Javascript. Is this a Template Method pattern or a Strategy pattern ? Both get subsumed into the prototypal nature of the language.

Web programming at a higher level of abstraction

Frameworks like Sproutcore, Cappuccino and Objective-J have given the Web programming model a huge leap. Till date one of the pet peeves of Web programmers had been the fact that the programming model was based on the native DOM and the associated accidental complexities that HTML, Javascript and CSS brought forth. The crux of the problem was not the polyglotism involved in Web development, but all these technologies were often found to be competitive with overlapping responsibilities. Frameworks like Prototype and jQuery took care of cross browser compatibilities, but still you are never sure whether to create a button in HTML or Javascript code or whether to use CSS files or apply styles in Javascript. In a summary, we have so far been trying to use lower level abstractions, which should ideally be abstracted away in higher order frameworks.

And Cappuccino does address this issue head-on. It turns polyglotism on its head and defines a common way to do things on the Web.

I was listening to the interview of the 280 North guys through a post on Ajaxian, where Francisco Tolmasky, the co-founder of 280 North, mentioned in one of the comments ..

"JavaScript does not have any way of writing applications today in the same way mature platforms like Cocoa do. Cappuccino provides you with very high level features like copy-paste (of anything), undo and redo, document management and archiving, vector graphics and animation, etc etc. when you write an application for Mac OS X or iPhone, you can truly focus *just* on your application, not whether it will work on some obscure browser or how to get something as simple as undo working, and that’s precisely what we are trying to provide."

As this Cappuccino blog post clearly indicates, the only purpose behind Objective-J was to provide the right level of abstraction for Cappuccino to be built on top of it ..

"The purpose behind Objective-J was to facilitate the development of Cappuccino, and when we originally set out to do that we simply wanted to add a few key missing features to the existing JavaScript “standard”. In other words, Objective-J is our take on JavaScript 2.0."

To me, the most important takeaway from all these is that you can now develop rich applications on the browser only without having to depend on any proprietary runtime. Google Web Toolkit has been generating compiled highly optimized Javascript since 2006, it will be really interesting to see how the compiler optimized Javascript generated by GWT compares in runtime perfromance with the on-the-fly generated Javascript offered by Cappuccino.

We are seeing more and more impetus on Javascript being touted as a compilation target. Sometime back I read that Gilad Bracha was also thinking in terms of a Newspeak port on V8. With invokeDynamic being blessed by Sun, dynamic language compilation will improve and we will be looking at more and more scripting languages targeting the JVM. And this is the right time that we embrace frameworks that promise higher level abstractions in Javascript, making the browser and the Web a more productive ecosystem.

I didn't know Javascript can do this !

The best part of learning a new programming language is the bag of surprises that await you at every line of your program. And it's almost always a mixed bag - things that you were confident of, often do not work the way all the blogs have claimed to be. Your favorite idiom that you have so long used in every design starts falling apart. And you start thinking in a new way, in terms of the language which you have started learning. Sometimes you feel bad when your favorite design pattern finds no place in the laws of the new land, but soon you realize that there is a more idiomatic way of doing the same thing.

I have been a passionate Java programmer for the last eight years and started the journey with the same sinking feeling coming from the land of C and C++. I missed the sleak idioms of memory management using smart pointers, the black magic of template metaprogramming and a host of other techniques and patterns as evangelized by the language called C++. Now when I learn new idioms from languages like Javascript and Ruby, I always try to think how it can be mapped to an equivalent construct in Java. Not that there is always a mapping between the dynamically typed world of Ruby or Javascript and the land of static typing that Java implements. Still it's always an enlightening exercise trying to emulate the best practices of one language in the other.

This post is about one such recent experience with programming in Javascript. I was trying to get some stuff from the front end - I had to write an abstraction which will do some computation based on those values. Some parts of the computation had a fixed algorithm, while some parts varied depending upon the environment and context.

Strategy ! I thought .. this was my first reaction to the solution. Since I am not using a statically typed language as Java, I need not implement the delegation-backed-by-the-polymorphic-hierarchy-of-strategy-classes idiom. And I knew that Javascript supports closures as a higher level of abstraction, which I can use to model the pluggability that the variable part of the abstraction demands. Depending upon the context, a different closure will be passed, and I could make the variable component a closure and pass it along into the main computation routine. But the problem comes up when you have multiple such variabilities to model in the same abstraction. For every such variable point, you need to pass a closure as an argument.

// closures as arguments
function WageCalculation(taxCalculator, allowanceCalculator, ...) {
    //..
}


Works, but may not be the best way to model in Javascript. After some more digging, I came across the details of the Execution Context in Javascript. All Javascript code gets executed in an execution context and all identifiers are resolved based on the scope chain and an activation object. And Javascript offers a keyword this, which gets assigned as part of the process for setting up of execution context. The value assigned to this refers to an object, whose properties become visible to accessors prefixed with the this keyword in the main function. Hence all variabilities of the abstraction can be made part of this context and made available to the main computation routine through the this keyword. And this is exactly what Function.call() and Function.apply() do for us!

Simplifying my example to some extent for brevity, let us say that we are trying to abstract a routine for computing the wages of employees. The wage calculation contains a few components, the basic wage, the tax and allowance. Of these, the percentage of tax varies depending upon the category of the employee, while the other components follow a fixed algorithm. For simplicity, I assume hard coded values for each of them, but applying the variation where necessary.

The basic abstraction looks like the following :

WageCalc = function() {

    // privileged method
    this.taxCalc = function() {
        // 20% of basic wage
        return 0.2;
    };

    // private static
    allowanceCalc = function() {
        // 50% of basic wage
        return 0.5;
    };

    this.wage = function(basic) {
        // and the calculation
        return basic - this.taxCalc() * basic + allowanceCalc() * basic;
    }
};


and I invoke the calculation method as :

var w = new WageCalc();
print(w.wage(1000));


for a basic wage of $1000. The tax calculation component (taxCalc()) is a variable part and has been tagged with the this keyword. This is the candidate that I need to implement as a strategy and plug in different implementations depending on the context. If I want to have another implementation where the tax percentage is 30, instead of 20, I just do the following ..

MyWageCalc = function() {

    this.taxCalc = function() {
        return 0.3;
    };
};


and invoke the wage calculation function, passing in the new function object as the context. This is what the apply method of Javascript Function does :

var w = new WageCalc();
print(w.wage.apply(new MyWageCalc(), [5000]));


Here new MyWageCalc() sets up the new context on which the this.taxCalc() of wage() method operates. Hence the new tax calculation functions with 30% of the basic and not the 20% as defined in WageCalc() function.

I have only started to learn Javascript, hence I am not sure if this is the most idiomatic way of solving the problem at hand. But to me it appears to be exciting enough to share in an entire blog post.

Why do they call it Javascript ? It's not Java and it's way powerful for a scripting language!

A couple of days back, I was enjoying Steve Yeggey's keynote on Software Branding at the OSCON 2007. Talking about the negative aspects of branding, he mentioned about Javascript, a name which never helped the growth of the language. Glenn Vanderburg, another noted Ruby convert, says in his NFJS writings:

I still think that naming decision was a bad idea. It caused no end of confusion. Many nonprogrammers never figured out that Java and JavaScript were two different things.

In an earlier post, I had mentioned how the Rhino scripting engine and externalized business rules in Javascript saved us the day in one of our client engagements. That experience had me thinking about the virtues of polyglot programming, usefulness of embeddable scripting engine in Java 6 and the essence of the JVM as the next ubiquitous computing platform. However, it took me some more time and a couple of more blog readings to realize the power and elegance of Javascript as a language. Indeed all the capabilities of Javascript within the browser are add-ons to the simple virtues that the language imbibes.

In gensym.org, David mentions about the following Scheme implementation of a snippet that picks up the maximum salary of a programmer amongst a collection of employees having various roles:

(define (salary-of-highest-paid-programmer records)
  (accumulate
      max 0
        (map salary
          (filter programmer? records))))


He observed that the normal Java implementation will be much more verbose compared to the Scheme one. I tried out a Javascript implementation for the same problem ..

maxProgrammerSalary = function() {
    return {
        maxSalaryFun : function(emps) {
            return reduce(
                Math.max,
                0,
                map(pluck('salary'),
                    filter(
                        callMethod('isProgrammer'),
                        emps)))
        }
    };
}();


The code looks wonderfully similar to the Scheme implementation in structure using the functional paradigms. I really feel bad now that I have chosen to ignore this language so long. Like Glenn Vanderburg, this is my personal story of coming full circle with Javascript.

Of course the above implementation uses a couple of functions, which we have to define today or get it from libraries like prototype. With Javascript 1.6 Array extras and the new features in progress for Javascript 1.8, almost all of them will be part of the core language.

Javascript as a language

Being a prototypal language like Self, Javascript's tryst with OO principles are very much different from the classical strongly typed model of Java or C++. Prototype based inheritance was made hugely popular by frameworks like prototype and enthused many UI folks to the world of practicing OO programming.

A language does not necessarily have to preach OO in order to be beautiful - Javascript supports encapsulation and separation of concerns in its very own way, as has been amply demonstrated by the Module pattern all across YUI. I can have my properties declared at the appropriate level of abstraction without polluting the global namespace. In case of the above function for computing the salary of employees, if we were to fetch the employee collection from some data source and need to define some helpers for the computation, we can have a nicely defined module that encapsulates the whole computation model in a separate namespace:

maxProgrammerSalary = function() {

    // this is not exposed to the global namespace
    var getEmployees = function() {
        // get the employee list
    }

    return {
        maxSalaryFun : function() {
            return reduce(
                Math.max,
                0,
                map(pluck('salary'),
                    filter(
                        callMethod('isProgrammer'),
                        getEmployees())))
        }
    };
}();


A Growing language

One of the definite indications of the growing popularity of a language is the growth rate and increasing rate of adoption. While I do not have any concrete figures on the latter, there have definitely been lots of buzz in the blogosphere about the increasing importance of Javascript as a language. We have started seeing frameworks like jQuery, with its own programming patterns and DSL based approach. jQuery custom selectors, along with chaining gives you the programming power of using FluentInterfaces - here is an example from recently published Jesse Skinner's article ..

$('form#login')
    // hide all the labels inside the form with the 'optional' class
    .find('label.optional').hide().end()

    // add a red border to any password fields in the form
    .find('input:password').css('border', '1px solid red').end()

    // add a submit handler to the form
    .submit(function(){
        return confirm('Are you sure you want to submit?');
    });


This snippet is a succinct one-liner that selects the login form, finds some stuff, repeatedly going back to the form after each find, makes some changes to them and finally adds a submit event handler to the form. All the complexities of query optimization and DOM scripting are taken care of by the jQuery engine. When we see lots of programming idioms being discussed actively amongst the experts, it is the sign of a growing programming language. In my short stint towards loving Javascript, I discovered great idioms for lazy function definition, memoization, currying and other functional programming patterns being discussed vigorously in the community. In an earlier post, I had also discussed about the plethora of developments going on in this space.

Thoughtleaders of the programming language community think that Javascript 2 is one of the contenders for NBL. It has lots of features which will delight you as a programmer. It is succinct, it is functional with full support of closures, it is prototypal and it is dynamic. You can add methods to classes even after instantiation. It's a different paradigm altogether from the noun-land of Java. And it's also the most natural glue to the browser. Learn to love it now or ignore it at your own risk.

Befriending Javascript

Jerry Seinfeld had once said that according to most studies, people's number one fear is public speaking. I am not very comfortable speaking in public, but as far as Web application development is concerned, my numero uno fear factor was Javascript. Since then I tended to avoid this beast like anything and promptly started proclaiming myself as the server side guy.

Days have changed, positioning of Javascript as the ubiquitous computing runtime for the Web has started getting more traction. We are seeing more standards evolving, Rhino bundling with the JDK has given the server side guys more options towards DSL based designs. Lots of stuffs are happening in the scripting world, in general, and Javascript, in particular. In one of my earlier posts, I had described how we used server side scripting to externalize business rules from a business application. This post is a continuation of my belated attempt at befriending Javascript, with a special mention about the functional programming capabilities using the language. Have a look at the following snippet :

map(compose('+1', '*2'), [1,2,3])


which produces [3, 5, 7]. This is Functional Javascript.

In one application, I had to do some list processing as part of client side validation in a financial application and get counts of tax/fees which exceeded a predefined max. I started the usual imperative way using the nuts and bolts of if-then-else and for loops. Things looked ok initially, but started getting clunkier when lots of similar variants in processing logic came up and the code started looking boilerplate. Some googling pointed out that with Javascript's functional power you can kick it up another notch. You can program to the map-reduce paradigm and make full use of Javascript's higher order functions to carve out your client side validation library.

Here are some snippets using Oliver Steele's functional Javascript ..

count_grt_max = function(array, max) {
  function count(total, element) {
    return total + (element > max ? 1 : 0);
  }
  return reduce(count, 0, array);
}


And when the validation logic gets more complicated with more and more clauses being added, use the full power of functional Javascript ..

// get the sum of tax fee values which pass the
// minimum and maximum criteria validations

reduce('x y -> x + y',
    0,
    select('>' + max,
        select('<' + min, tax_fee_values)));


While this may seem an unnecessary functional engineering at work for a seemingly trivial task, there are situations where you surrender yourself to the temptation of beauty and sacrifice an element of utilitarianism. And, of course there are use cases in every application, which do not need the raw harness of your favorite performant enterprise language. Use the many functional javascript libraries to spruce up your client side scripting - remember you can use the same scripts for server side validations as well (wow! Rhino!).

The Language

Douglas Crockford notes that

... JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.

all the spices to spruce up your lambdas and closures ..

Erik Kidd is working up to a Ruby esque metaprogramming library for Javascript including porting of RSpec, and Steve Yeggey has butchered Rails into Rhino. Prototype has added lots of Ruby features into Javascript, which are now being used as the base to implement ActiveRecord like features in TrimPath. After a two year hibernation, it is good to hear that TrimPath is being defrosted. With TrimQuery, you can write the following query on the client side for structured Javascript data records ..

// First we precompile the query language object with the schema...
var queryLang = TrimPath.makeQueryLang(columnDefs);

// Next, we do a SELECT statement.
var statement = queryLang.parseSQL(
    "SELECT Customer.id, Customer.acctBalance, Invoice.total " +
        "FROM Customer, Invoice " +
        "WHERE Customer.id = Invoice.custId " +
        "ORDER BY Customer.id ASC");

// Here we run the query...
var results = statement.filter(tableData);
//..


And none of the above is strictly about the Web - there is a growing community enriching the usage of Javascript as a language.

Google Gears - another reason to learn Javascript

Talking about client side persistence, Gears offers a framework for creation of offline browser applications with an embedded SQLite relational database system. Gears offers Javascript APIs for creation of databases, manipulating data and processing resultsets.

var result = db.execute(
    "SELECT * FROM persons"
);
var fieldCount = result.fieldCount();
while(result.isValidRow()){
    for(var i = 0; i < fieldCount; i++){
        var value = result.field(i);
    }
    result.next();
}
result.close();


And Gears is a framework which works offline without the server connection - it is meant to develop applications for the browser, not only for the Web. The rich set of Javascript APIs allows us to build client side persistence on top of a database service. Javascript is no longer the lingua franca for the Web only - it is turning out to be a rich platform for client applications in offline browsers as well. In the server side, as well, Javascript is making an emphatic comeback. Projects like Helma is an ample testimony towards this. For more news on advancement of Javascript as a language, have a look at this document.

Is the browser going to be the next ubiquitous computing platform ? I need to do a lot of catching up ..

Customizable Business Rules using scripting on the Java Platform

Executing Javascript within the JVM has opened up a new avenue to add to your architectural paradigms. In today's enterprise applications lots of code (validations etc.) needs to be run both for the client and the server. Often we find repetitions in the form of Javascript for the client side code and Java for the server side. With server side Javascript being thrown up as an option in the JVM, the same client side code can be executed within the server using the ScriptEngine of Mustang. Rails people will suggest writing DSLs, which can be converted to Javascript and executed within the JVM.

This post is about using the new architectural paradigm in a project which we executed recently for a publishing house. It was a medium sized project where lots of stuff used to be run in VBScript within ASP.NET. The hapless users wanted to migrate to the JVM and sync up the application with the rest of their MIS running on big Java platforms. No additional functionality was needed to be developed. The VBScript code generates lots of SQL using complex business logic, which ran in the .NET server platforms.

Problem #1 : We do not know what the VBScript code does!

This was the first shocker that we received when visiting our client. The developers who had written the code have left - does this ring any bell? The usual problem of migration - and none of the existing MIS managers where prepared to explain us the flow of the business logic as they exist today.

Option #1 : Go dig it out ..

Struggle through the reams of VBScript code (no code comments - we are dynamic!) and enlighten yourself with the existing business process flow. The only thing that we realized was that all those VBScripts were being used to prepare tons of SQL queries that were later executed in the server. And that the logic code had the usual share of complicated if-then-else that sets up the SQL statements.

Problem #2 : We want externalization of business rules that exists today

The users today have the flexibility of manually tweaking SQL queries and minor business logic in the customary VBScript style of operations. And since some of the business rules change quite frequently, they need to have the same flexibility in the new system as well.

Wow! Rhino!

After shuddering in the thought of cost overrun that Option #1 would incur, we decided to look for an alternative. And there it was - the new scripting engine available for executing Javascript within the JVM. Without going into the details of the business logic, we took the route of converting the VBScript code to Javascript and then spitting out the result to the Rhino interpreter. This will also solve Problem #2 as well, since the same business logic will be available to the users today, only on a different scripting platform. The conversion process was made easier by googling some tools crafted by one generous soul. We wrote a script handler ourselves that we could invoke and execute all scripts from within the main Java application ..

boolean loadScriptFile(String fileName) {
  String jsFile = fileName + "." + scriptBean.getScriptExtension();
  InputStream is;
  Reader reader;

  try {
    is = this.getClass().getResourceAsStream(
      scriptBean.getScriptingSourcePath() + jsFile);
    reader = new InputStreamReader(is);
    engine.eval(reader);
    //..
    //..
  } catch (ScriptException e) {
    //.. handle
  }
  //..
  //..
}


The script handler had an initialization code that set the environment up for all executions to take place in the later stages .. we had developed a utility library which also needed to be bootstrapped ..

private void init() {
  ScriptEngineManager engineMgr =
      new ScriptEngineManager();
  ScriptEngine engine =
      engineMgr.getEngineByName(scriptBean.getScriptingEngine());

  try {
    // execute utility library
    InputStream is = this.getClass().getResourceAsStream(
      scriptBean.getScriptingSourcePath() + "defaultScripts.js");
    engine.eval(new InputStreamReader(is));

    // set up values in the state of the ScriptEngine
    engine.put(SCRIPT_RESULT_IDENTIFIER, engineResultList);
    engine.put(SCRIPT_MAP_RESULT_IDENTIFIER, engineResultMap);

  } catch (ScriptException e) {
    //.. handle
  }
}


In the above example snippet, the put() method allows assigning any variable used in the scripting environment from within Java code. Another alternative will be to use Bindings. Suppose we have a list of names in a java variable listOfNames, which we need to provide to a script to form an SQL statement ..

engine.put("namesKey", listOfNames);


and the script to be loaded contains the following ..

function performancePubReg() {
  //.. form the sql
  sqlStr = "select ...
  sqlStr = sqlStr + "where master.name in " + makeString(namesKey);
  //..
}


In course of the application, wherever we needed to execute queries, these sql queries were fetched by load-eval of Javascripts using the script handler implementation.

A Useful Extension to the Architectural Toolbox

In general, this approach proved to be a useful paradigm for small to medium sized migration projects. In an ideal scenario, these customizable business rules which generate SQL queries could be coded up as a DSL for the business users and then appropriately converted to any scripting platform. And the best part is that you need not always dig into the details of legacy code in situations like ours.