Daniel Pitts’ Tech Blog

Almost Useful: Operator overloading

Daniel, December 4th, 2007

On suns site, there is an open bug for operator overloading. Many people have pointed out that Java has one special case of operator overloading (String + String), so why not allow the programmer to overload operators?

Operator overloading would become especially useful when the addition of the units and measures API, or other custom libraries that are similar. It becomes especially useful when trying to avoid primitive obsession, and create numeric-like types.

Imagine this case:

Speed s = endDistance.minus(startDistance).divide(duration);

could be simplified to

Speed s = (endDistance - startDistance) / duration;

This of course is a simple example, and yet one that I would love to use in some of my existing code-bases.

Another use case would be a cleaner syntax for lists/maps:

myMap["Hey"] = "There";

And hey, what about a special case for compareTo? Although it might be too dangerous to overload =/==, I could see overloading <, > <=, and >=. It might be nice to add a couple of operators to the mix. I’m officially suggesting “#” for concatenation. Maybe “:=” for shortand to .equals().

Tags: , , ,

4 Responses to “Almost Useful: Operator overloading”

  1. Aviad Ben Dov Says:

    It’s easy to take a look at where operator overloading is the good case. But let’s not forget that the operator overloading debate is a really old one, and goes back at least 10 years in the life of Java. Take a look at a similar post of mine, I wrote some about it and in a much better way than I’d bring in a comment here. :)

  2. Aviad Ben Dov Says:

    One of the problems Java has is that the collections framework was never a part of the designed language features, it was added later; therefore, it didn’t get a “spot” like String, and you can see that only recently a “foreach” was added to reduce the verbosity of the Iterator class.

    To follow that line of logic (of adding ease of development features which make use of common interfaces, such as the Collection interface which was extracted into the Iterable interface), I see that it makes sense for the Java developers to add another EoD feature that relies on an Indexer interface which allows people to use the square-brackets-with-index syntax.

    Just my couple of cents, but now that I wrote it here I find it interesting and I might make a whole post about it on my blog ;)

  3. Chaotic Java » Blog Archive » Who wants Indexer as the next EoD feature? Says:

    [...] fact, just today Daniel Pitts posted something about it under his “almost useful” tag. In that, he obviously mentions the convenient square brackets [...]

  4. Ricky Clarkson Says:

    I agree in principle, though I don’t feel strongly about it. I’d like to suggest you take a look at how Haskell does it. Even the built-in types, such as Integer, can only use +, -, * and / because they are a member of the Num typeclass (similar to implementing an interface). So if you want to make a new type able to use those operators, you make the type an instance/member of the Num typeclass. That means if you overload +, you have to overload *, etc., which arguably is better than allowing individual overloads.

    You could also take a look at Scala, in which all that punctuation can disappear, which leaves normal method calls easier to read:

    val s: Speed = endDistance minus startDistance divide duration;

    It’s evaluated left to right, by the way, divide can’t have a higher precedence than minus, because they’re both method calls. I think there are languages in which a method call can decide its own precedence, but Scala isn’t one of them.

    So in general, for Java, I’d suggest some classes/interfaces that provide those operators. You mentioned Comparable for <, , >=. I think it seems a little strange for == to possibly contradict <=, so I reserve judgement for now.

    I suggest Number gains the necessary extra information to allow user classes to define their own +, -, * AND /, at least, and possibly an extra class/interface to add more esoteric things like %, a Bitwise interface for ~, ^, |, &.

    I think a few small measures like this could allow operator overloading without sparking fears that Java is turning into C++ (the usual complaint, despite C++ being only one of many many languages that support operator overloading).

Leave a Reply