I have to confess that I really don't understand this idea that operator overloading somehow makes code harder to read. Yes, people can write obfuscated code using overloaded operators, but they can also choose obtuse message names and it's not considered a flaw in the language. Used properly, operator overloading makes code substantially more readable.
Recently I had cause to add an NSTimeInterval to an NSDate. If I was writing this in a language with operator overloading I'd have written: endTime = startTime + delay
In the absence of operator overloading I instead have to write: endTimer = [[[NSDate alloc] initWithTimeInterval: delay
sinceDate: startTime] autorelease]]
Can you honestly say that the former is harder to read than the later? The exact implementation of the addition process is hidden from sight but this is a feature, not a bug. It's called abstraction!
It's interesting to note that if the language grew the capacity to handle operator overloading through mapping of operators to appropriately named messages it would be relatively easy to retrofit support for this into existing libraries; all you have to do it write categories to support the new operators. This also means that you don't have to add complex support for trying to map to "left" and "right" forms of operator since if I come up with a new class and I want to be able to have it as the right-hand operand dealing with an existing class then I just add a category to the existing class.
by Nicko — Sep 21
Recently I had cause to add an NSTimeInterval to an NSDate. If I was writing this in a language with operator overloading I'd have written:
endTime = startTime + delayIn the absence of operator overloading I instead have to write:
endTimer = [[[NSDate alloc] initWithTimeInterval: delay sinceDate: startTime] autorelease]]Can you honestly say that the former is harder to read than the later? The exact implementation of the addition process is hidden from sight but this is a feature, not a bug. It's called abstraction!
It's interesting to note that if the language grew the capacity to handle operator overloading through mapping of operators to appropriately named messages it would be relatively easy to retrofit support for this into existing libraries; all you have to do it write categories to support the new operators. This also means that you don't have to add complex support for trying to map to "left" and "right" forms of operator since if I come up with a new class and I want to be able to have it as the right-hand operand dealing with an existing class then I just add a category to the existing class.