Why not Operator Overloading in JavaScript?

Disclaimer: Some of this post arguments are inspired by the great talk by Guy Steele: Growing a Language. So I was checking out the new JavaScript spec. (ECMAScript 4) lately, and I was very surprised (and disappointed) to see that Operator Overloading wasn't even accepted as a proposal for ECMAScript 4. I've noticed last year that the proposal was denied by all browser vendors, as you can see in the ECMAScript 4 progress spreadsheet created by John Resig, under the name of "Operator Overloading". This is heartbreaking for me... let me explain you why.

Why Operator Overloading (in general)?

Operator Overloading is a special case of polymorphism, in which operators like +, /, *, ... can be overloaded by the user. This is very useful in languages where the user can define special types (or classes), since it allows the developer to use notation that is closer to the target domain, and allows user types to look like types built into the language. What Guy Steele said about Operator Overloading is that: "If we grow the language in these few ways, then we will not need to grow it in a hundred other ways; the users can take on the rest of the task." To see why, think about these structures:

• 2D, 3D Vectors
• Matrices
• Intervals
• Complex Numbers
• Polar Coordinates
• Rational Numbers

One thing all these structures have in common is that their sum and product operations have a different definition than the one we give to integers. There's also an interesting fact about these structures: a lot of people use them, but a lot of people don't. For example, Matrices might be used by OpenGL/Direct3D developers, but it's not very common to use this structure for manipulating the DOM or building AJAX applications. However, each of these structures must be considered in any programming language. Adding them all into some standard library might be too much. However, sooner or later, some developer will want to use them. Here's the dilemma as exposed by Guy Steele: "I might say yes to each one of these, but it is clear that I must say no to all of them!". Operator Overloading solves this problem by giving the user the power to overload built-in operations and turn a non-domain specific language into a perfect tool for a developer's specific needs. By using Operator Overloading a developer can define operations on any custom type and its use will blend perfectly well into the language. Wouldn't be just beatifull if a and b beeing Complex Numbers, we could do this: instead of this? : Ok, so now that I made my point about the power of operator overloading, let me explain you why I think this should be more carefully considered by the new JavaScript spec.

Why Operator Overloading in JavaScript?

To see why we should take seriously Operator Overloading in JavaScript, we first have to take a look at what happened to JavaScript in the last few years. Only one thing happened to JavaScript in the last few years, AJAX. The XMLHTTPRequest concept was first created by Microsoft, and wasn't part of the web standards. They first used it in the year 2000, but a couple of years later Mozilla, Safari and Opera were also implementing it. The standards covered that topic a lot of time after it was already implemented in all major browsers, and AJAX was already in the wild. One strong aspect of JavaScript that was pretty important and that, IMHO, made the adoption of the "AJAX paradigm" a lot easier, is that JavaScript was already compliant with the "event-driven" programming paradigm, and the use of the XMLHTTPRequest object didn't add anything new to this paradigm. Just as callbacks were added to respond to DOM Element's events, callbacks were used to handle server side answers. Although AJAX changed the way web applications were created, it did that by mantaining the event-driven programming paradigm. Oh, another thing happened to JavaScript in the last couple of years, Canvas. Canvas is following the same trend the XMLHTTPRequest object followed. It has been adopted by most browsers (Opera, Gecko, Webkit) and despite Internet Explorer's efforts to not adopt this new feature, libraries already exist to make Canvas compatible with IE (to a certain point). A couple of nice libraries that used Canvas were released last year: John Resig published Processing JS. Some other libraries that make use of canvas were also released, one of them is the JavaScript InfoVis Toolkit (my library! :) ). The number of Canvas related stories really grew at Ajaxian, and there were also new breakthroughs by Opera and Firefox on the implementation of Canvas 3D. There is one caveat to this Canvas thing though, it doesn't use extensively the event-driven paradigm. Since all these Canvas implementations are related to Cairo and also take things from OpenGL and Direct3D (this is notably the case for the Canvas' 3D API), IMO these concepts are more related to a functional programming paradigm than anything else. I mean, 2D/3D graphics are all about geometrical operations. And geometrical operations are mathematical functions. These concepts might be harder to grasp than the ""AJAX paradigm"", and that's why the adoption curve won't be as high as the AJAX one, but there's no doubt that Canvas developers are a niche. And do you know which objects/types/classes are related to geometrical computation, Canvas, Canvas 3D, Cairo, OpenGL and Direct3D?

• 2D, 3D Vectors
• Matrices
• Intervals
• Complex Numbers
• Polar Coordinates

That's exactly what I mean. The next logical step to bring a easier use for Canvas related programming should be operator overloading. This is the one feature that will be extensively used by JavaScript Canvas developers, since they have to deal with points, 2D and 3D coordinates all day. For a last example, consider an interpolation function between two complex numbers The same thing with operator overloading would be: You would make a developer's life happier. Comments blog comments powered by Disqus