Monday, June 22, 2009

Avoid having your Scala code turning into APL

With the rise of languages that support operator overloading like Ruby, Groovy, Scala and C# one is justified to wonder if libraries will become loaded with unreadable APL like code.
I have already seen signs of the potential chaos that could come from the abuse of operator overloading. In the Scala actor library tutorial for example I have seen the following:

producer ! Next


I was initially unable to guess the meaning of this.

The following example is from a Ruby library:

(aobject / 'a string')


In this case because I watched the full presentation I know that the slash is actually an alias for a search method.
The speaker in the presentation was calling this cool. I call it stupid. It is the archetypal example of a bad use of operator overloading. The presenter himself said he was puzzled and could not understand what the code was doing at first. Definitely not cool.
Since I'm looking at switching to Scala as a main language I thought I needed to think about what kind of rule I would put into our code convention document under the section
Operator Overloading. I thought I would share this with others to get inputs and hopefully constructive comments.

For me, the best applications of operator overloading makes the code easier to understand.
Here are some example of this:


Mathematical operations (+, -, *, /)

This is the best application for operator overloading and as long as you don't
start doing stupid things like using operators in a way that conflicts with established
conventions you should be OK.

Logical operations (&. |, ||, ..)

This should be used on boolean values. One acceptable extension of this is to
use them in cases where we have implicit conversion to boolean. They don't really look like their textbook equivalent but they have been in use long enough in enough languages to be used safely.

Comparisons (>, <, ..)

Use those on any set of ordered elements. The meaning should be obvious. For example:
myWeight > aWeight
Beware of things like:
myDog > otherDog
where we don't exactly know how things are being compared.

Operations that are metaphorically related to a mathematical or logical equivalent

Using the + when you want to add a string to another for example.

Operators used as part of method names

Of course this is not operator overloading but since it is another use of operators that can lead to abuse and unreadable code I include it here. In those language that allow this, using ? as a suffix for queries for example is OK. The meaning is clear and makes the query stand out. In this category I think that % and $ could be used if allowed by the language. The only other case that I can think of is the exclamation point as a warning that a method call might have side effects. This last one is not as obvious and is at the limit of what is acceptable for me.

Operators that are already used in the core libraries of a language

If those operators have been around long enough and it is too late to remove them from the standard library then we have no choice but to use them.


All other uses of operator overloading is suspicious. The worst offenders of course are operators used as meaningless abbreviations for method names.

In some cases you will have to watch for compiler quirks and language peculiarities. WIth C# for example when you define the ++ operator on a class it has the same semantic when used as a prefix (pre increment) or
suffix (post increment). In both cases this works like a pre increment operation. This is a bug factory.
In this case I think the compiler should give an error when ++ is used as a post increment operation because it will not have the expected result. You get the same thing with the -- operator.