The best implementation of operator overloading I've seen (next to Lisp's ;) is Ruby's - you just define methods named ==, <, etc. The C++ mechanism is really ugly - they just go for more syntax, like the operator keyword. Python's is better, but still ugly - you define methods named __eq__, etc.
The beauty of Ruby's system is that there is very little language support for it. In Ruby,
- Characters like ==, = and ? are allowed in method names and other identifiers
- Methods can be called without () at the end; simply give the arguments after the method name
if dog.hungry?Since + is a valid method name (and numbers are objects), you can say:
The only support Ruby gives for operator overloading is to allow the dot to be removed. The rest of it follows automatically from the power and flexibility that's already there.
I find a model that says, "the operator + maps to the method +" to be more straightforward than one that says, "the operator + maps to the method __add__". So + and .+ is just the operator/method duality - when you look at it as an operator, it's +, and when you look at it as a method, it's .+ .
Incidentally, the very same power simplifies properties (things that look like instance variables but are backed by methods) - a read of a property dog.age is just a call to the method age with the parentheses removed, and a write is a call to the method age=. How elegant!
With a no-distinguished-object style (where the self argument is syntactically treated similar to the other arguments), unless you have prefix syntax, mapping a+b to +(a, b) is little more of a syntax transformation than mapping it to a.+(b). But there's a transformation going on in both cases, so I suppose there isn't much difference. And I would still prefer overloading + by definining a function named + rather than __add__ (or another name).
Last Modified: 13 Jun 2006