Chaotic Java

Operator Overloading has been a case for long time debates, and I figured I could throw in my couple of words about the subject.

Asking me what I think of operator overloading in Java is a tricky question: I’ve been through all possible camps by now, both in the supporting and non-supporting sides.

The obvious question is why would we want to overload operators? The answer is simple: Consider having a complex number class, and the next piece of arithmatic expression: a * b + c * d. The compiler knows to calculate a* b and c * d first and only then add the results. Consider the same in code: a.mul(b).add(c.mul(d)); And that, my friends, is why we could use operator overloading.

There are several problems with operator overloading though, some of them I will count down here:

• Operator Abuse This is much like writing bad code. Call a method “println” and have it generate numbers. But that’s not what I mean here. Operator abuse examples are using the + (plus) operator for adding between collections, using the - (minus) operator to remove elements from an array, using the [] (square brackets) operator to call methods, etc.
• Consistency Operators should be consistent. Meaning, you would expect a += b to be the same as a = a + b, and some more consistency patterns. Implementations hardly remember that, and create situations where the consistency is not there.

Let’s examine the operator overloading we have today, on two popular languages: C++ and C#.

Operator Overloading on C++

Possibly the language with the most “freedom to code”, C++ allows you to overload any operator you want. However, with freedom comes a great responsibility. For example, if you would implement ComplexNumber& operator +(int r), you would also have to implement the operator += and the operator for the other way, this time as a static method: static ComplexNumber& operator+(int r, const ComplexNumber& c);.

There were other problems with C++ regarding consistency, but I rather look at how these are solved in C#, which is a newer language.

Operator Overloading in C#

C#, and the dotNet framework at large, are new in the world. C#’s developers had the experience of previous languages and know what pitfalls lie before them when implementing operator overloading. They still wanted to give this option to the language users, as they figured it’s a useful, powerful tool.

However, they apparently fell in their own pitfall. First, the operator abuse. The C# event system, for example, uses the operator += and operator -= to add and remove delegates from the event handlers list.

The second problem actually derives from C#’s attempt to solve the inconsistency problem to a certain level. Instead of allowing operators to be declared as part of the class’s methods, they are declared as static methods. This prevents a case where a == b throws a null pointer exception just because a is null: The call is not made through neither a or b. This causes a design problem: Static methods cannot defined in interfaces, and so - I can’t define an interface having any operators. And more - I can’t use operators on generic types, a problem addressed here.

Again as with C++, implementing the operator + for one direction means that you have to implement it in the other direction as well, otherwise it will be inconsistent.

Operator Overloading in Java

Java never had operator overloading. Debates had been on Java forums for decades, and a simple, relatively new example can be seen here. Much like multiple inheritence, operator overloading was seen as a problem and decided to be left out of the language. If you ask me, I don’t see operator overloading entering Java any time soon.

It might be sad, but it’s also for the best in a way. However, I’m sure libraries are out there which support pre-compilation of Java code to use some sort of operators, made especially easy with products like AspectJ and AspectWerkz.