Why classes?

I want to continue with the philosophical ground work underlying ZJS. I have already touched on the centrality of “class” to OO programming. There is some debate, though, on this topic as it relates to JavaScript. For example, this excellent article by Douglas Crockford (a JavaScript luminary) describes how he has moved away from the classical style all together.

Even so, every major JavaScript framework (e.g., ExtJS, Dojo and YUI) that I have used includes, at its core, a class emulation mechanism. I don't think this can be solely attributed to the desire for familiarity of expression on the part of those coming from more classical languages. As I see it, the reason for this is that the “class as a unit of functionality” paradigm is extremely compelling.

Sidebar: I was very disappointed when the C Standards committee decided to not include “class” in its future plans. Their reasoning, as I understand it, for shunning classes was a total strawman argument: the logical culmination of that path would be C++ (which I suppose many C programmers view as over-bloated). It does not take formal training in logic to see that this argument is vacuous. It would have been beneficial to C even if classes only supported single inheritance. In fact, C++ won the hearts of many while it was in that state of its evolution.

Sorry for that. Now that I'm back from my rant, I imagine you can tell where ZJS began: I wanted to see how close to a classical, declarative style I could get with JavaScript. Of course, the first question to answer was “what is a class?” or alternatively “what features should class emulation provide?”. For starters, the inheritance mechanism provided by JavaScript (the prototype chain) is a single link list of object-to-prototype. Virtually all class emulation approaches are built around the prototype chain and for good reason. So this answered the first part of the question: single inheritance. While multiple inheritance can be simulated, I think it goes against the core of the language and wouldn't work well with other features that I had in mind. This approach worked out well for Java and C# and, while multiple inheritance is available in C++, it is typically shunned by practitioners.

These languages are not, however, dynamic languages and as a result, as Douglas Crockford again pointed out, JavaScript can be a more capable language. I do think these capabilities come from JavaScript being a dynamic language more than from its use of “prototypal” inheritance. So, when I set out to emulate constructs (like class) from static languages, I wanted to avoid limiting the dynamic capabilities of JavaScript.

For this reason the core mechanism for class definition in ZJS uses the more general concept of $mixin. What $mixin does is provide a means to extend an already defined class. This is not inheritance because $mixin does not create a new class: it modifies an existing class. By defining classes in this manner, users of libraries are able to safely inject logic into library-defined base classes.

In the version 3 of ZJS, $class is now even more connected with $namespace to provide scoped lookup support which, to my knowledge, is unique in the JavaScript world. Not to boast or anything; I have found many good ideas and inspiration in other libraries. For example, the whole concept of conditional members I borrowed (and extended) from base2.

I mentioned in my previous post that I have little hope that the JavaScript community will ever converge on any library as a platform on which most (or even many) other libraries are built. This is sad because there would many benefits to a common solution to these problems. The first would be a single learning exercise for users instead of learning a new approach for each library. A second benefit would be interoperability between libraries. Today, one must use the appropriate, library-defined mechanism to extend or derive from one of its classes. I won't continue, but I still hold out hope that these ideas can cross-pollinate and eventually lead to similar features and (hopefully) syntax in other libraries.

In summary, on the aesthetic level of syntax, I think ZJS has achieved as elegant a solution as can be had in JavaScript. See my comparisons for examples in various frameworks. I am interested to hear what others think, so do drop a comment or two if you have chance.