User defined operators don’t seem objectionable in actual practice. I’ve rarely seen them abused in real C++ programs. There are plenty of features that can be misused, but most are not because of education, social pressure, or most often just good sense. The programmer who overloads + for Apples would be likely to write a plus() method too.

Units and range restrictions are something I really, really miss in Java. These are so awkward to implement that people use unitless ints for their apples, which does allow the dreaded apples**2 . Allowing operator overloaded and/or implementing units would surely reduce the number of squared apples.

What if it’s the case where we have no choice but to overload a bunch of math operators?

Combine this with something like C++09 concepts, which do a compile-time check on the operands, and you get compile-time safety for these overloads (well, its possible even with C++98, but its non-trivial).

This outlines an important fact: operator overloads are *very* useful, BUT need very strict checks, since they can be abused very easily. C++ is getting there with concepts, Haskell got it right. Java decided not to deal with that problem simply by throwing out operator overloads altogether, thus diminishing its expressiveness. (Its real sin are the heavily castrated Generics, though - if Java Generics were a match to C++ templates, it would be a far more powerful language, especially because they had the chance to design a different syntax, much better suited for the tasks that C++ templates are used in today).

A great problem seems to be that many people still see operator overloads and the like from a 90s point of view. Just have a look at stuff like Boost, Generic Haskell, the upcoming C++09 standard, and then talk about operator overloads again.

In any case, here’s the problem - I can get behind the claim that there are very few reasonable uses of operator overloading other than the canonical mathematical ones (vectors, matrices, big numbers, quaternions, etc.). The apples/oranges example is not great. That’s fine. But since Java doesn’t include a decent assortment of mathematical objects that follow usual mathematical notations within the language, it is ridiculous that it also doesn’t include the ability to add this functionality. This is why people keep complaining - because they are tired of the parenthesis-soup that results when you try to write out simple vector equations.

If Java contained built in Vec2, Vec3, Matrix, and Quaternion types that used the usual operators (yes, I understand that adding two matrices of different size would cause an exception), I would be happy (happier if they behaved as value-types and could be reasonably quickly created for temp purposes, unmet-and-delayed promises of escape analysis notwithstanding), and I would gladly accept the fact that it allows no operator overloading. Lacking that, Java is obnoxiously deficient for mathematical purposes (which, to be fair, Sun has told us many times they don’t care very much about), and the only reasonable solution I can see is to allow overloading.

If you want to protect everyone from the bad programmers, then you have to at least give the good ones the tools they need to be productive and write readable code. Otherwise Java will continue down the path it’s on, until its sad death when all the halfway decent programmers have decided that they have no interest in programming a weak language that’s designed for bad programmers. I truly hope this doesn’t happen, because I happen to love the language otherwise.

But as I’ve gotten older, I’ve grown to dislike it intensely.

Back when we engineers were taught to use slide rules, we were taught to work out the units in our head. Feet x pounds should give you torque, in either foot-pounds or pound-feet.

The idea of ‘apple^2′ is really dumb. Its not often part of folks brainwaves, but you never multiply money, you multiply one money quantity by a dimensionless number.

I totally agree. then again, I have a BS in Mathematics, and like fields, groups, isomophisms, etc.

Other cases where I’ve used operator overloading (in C++) involved “normal” types that were wrapped in a class because they needed to be proxied somehow: atomic integers and pointers, byte-swapped integers, and objects in another address space which have to be accessed by DMA. (The last for the PS3 SPU.) All fine candidates for overloading.

In each case, you must come up with a sensible set of methods (once complete, consistent and well-defined you can even call it an algebra), give them proper names (plus or +, minus or -, … whatever), implement and document them. In the end it remains a matter of style not substance, and I prefer the more concise mathematical operator. Let me have it.

In the end let the marketplace of ideas, of APIs decide which ones are being used by programmers, not some self-appointed style police.