A Blog about Business, Enterprise Architecture and Software Design by the Founders of ZenModeler

Class Or Objects Whats The Deal

Recently there have been a lot of articles published and frameworks built which debate about whether or not the notion of Class should be added to Javascript? In this article, I give my humble opinion on that debate and where my focus is : on the type system, not on syntactic sugar about the class keyword before my object constructor.

For those who instantly start to snicker at the mere mention of Javascript they should know that it is THE language of the moment and that it has very solid foundations from a theoretical point of view… well, ok, less so from a practical point of view (see « Javascript the good parts »), but node.js has been in first place on github in the end of the year.

I am surprised by this desire to add the class concept to Javascript because it seems to me to be a perversion, in the etymological sense of the word: « action to divert something from its true nature ». Indeed, the notion of class is absent from the principles of conception which make up the foundation of Javascript language, and they are:

As a reminder, Javascript is inspired by Self (I also recommend this excellent article « Self, the power of simplicity »), the first language to actually put into practice this principle of Prototype. I have been passionate about the object paradigm for several years now and I would like to add my point of view to the debate at hand, my blood turning cold from reading certain articles. Wanting to add the concept of Class to Javascript is in my opinion a non-issue and I will demonstrate this in the following sections.

Class, type and interface

A type defines an interface and a behavior, while a class defines a particular implementation of this interface and behavior. The class-concept is hence an implementation of the type concept. A type is defined by an interface and a behavior, that is its attributes, but most of all – and most importantly in my opinion – its methods. In Javascript, these notions of attributes and methods are stretched to encompass the notion of properties (or slots) without any sense of visibility. I like the visual aspect of the term “slot” because it illustrates the dynamic aspect of Javascript objects. And so, the class can be seen as the blueprint of the soon-to-be created object.

To introduce the class-concept in Javascript would be to deny its highly dynamic nature, in other words denying it the possibility to add during execution functions and attributes to any object. Nevertheless, class is interesting because it allows to join in the same spot the constructor, the attributes and the methods. What bothers me is how focus is put on an abstract concept (class) and how it is considered to be static although what’s really important is the object, which is extremely dynamic and hence potentially weakly linked to its class. Basically if you want static instead of class see Dart by Google.

How should a new object be built? the constructor

The most important element in object-programming is actually the object concept, and especially everything in relation to its construction. This is why the notion of constructor is so important to class-based language (Java, C#, etc.). In Javascript, the keyword “new” followed by the name of a function insures the mechanism of constructing a new object. This way the notion of class doesn’t appear anywhere in the language. Furthermore, I find it rather remarkable and amusing how in Java the only moment when the class name appears is behind the keyword “new”.

The concept of heritage allows an object to dispose of the slots of another object. The inheritance-concept being supported by the “prototype”-object  associated to the newly-created object (this works sort of like in a chained list) where the executing motor searches for unknown slots by reviewing a list of “ancestors” from the bottom.

Contract, classification and typing

How should an object be “classified” and how to be assured that an object belongs to a given type and so answers to an interface? Behind all this I believe sits the question of the behavior – “how is this object going to react faced with this message?” – in application of the substitution principle developed by Barbara Liskov.

Strong typing allows then to validate the interface, but only in its global signature and not in the behavior. Programming by contract concept provides this kind of mechanism of validating behavior before the execution. This isn’t available in Javascript so I would rather turn to unit test frameworks which I use in a Behavior-Driven Development sauce and that I sometimes summarize by “programming by contracts within tests.” In CoffeeScript the Contracts.coffee extension has very recently made this mechanism available directly.

My ideal language? One based on prototypes, strongly typed and dynamic

In an ideal world I would like a language based on prototypes, strongly typed and dynamic. What is important to me is:

  • How do I build an object and how do I define its attributes and the functions linked to its changing states?
  • What is the behavior of an object at an instant t in time and based on the context?  Well yes, I am interested in the Data/Context/Interaction pattern derived from the works of Trygve Reenskaug, the inventor of the MVC, and James Coplien. Javascript’s dynamic nature is perfect to put into action the mechanism of trait or mixin, allowing the composition of different behaviors (hence functions) at the heart of an object depending on the context.
  • What is the contract of this object and how can I assure the correct use of it? possibly before code execution

Python is one of the closest language from that ideal, but I find the new kids on the block (Dart, Contracts.Coffee inspired by Racket, etc.) to be smart enough to gently allowing introducing strong typing when one has the most need of that feature.

The mechanisms that I put into place in my programs in order to ensure their robustness rely heavily on contracts. In Javascript, I don’t have such mechanisms, so I do differently : essentially I check through testing the asserts and contracts that I expect to be true within my code. But I am really eager to try that new languages.

Conclusion

To summarize, I find Javascript very healthy and very useful with palliatives that are in the end easily put into place. With my experience, I have developed my own style of design and programming that fits me very well by dipping into concepts and not into implementations and I always manage to find what I’m missing. So, in a nutshell, I don’t need classes but a richer type system and for me the future is bright given the pretenders. What about you? What do you need most from your everyday programming language?

Update the Feb 10 :

This discussion about « untyped » on Stack Overflow give a lot of clues about that subject.