There was a recent thread about things people don't like about Java. In it, operator overloading was put forward as a feature that Java needs. This article from a C++ game programmer explains why I don't like the idea of making code look like one kind of operation when it's really something else:

I though operator overloading was just unneccessary syntactic sugar until I spent some time debugging an operator sequence where it would have been easy to spot the error using operator overloading.I don't use it anyway though

You're way more clever than me if you could understand it in less than a second glance.

You struggle to understand a sequence of operations using the standard method calling syntax of the programming language you use all the time? It reads left to right like all method chaining sequences in Java do - if you've ever read Java code, it should be obvious.

I don't understand it at first glance either. Main problem being chaining method calls - horrible style.

hmm ... now I really like this style (when the API is designed for it). I find it cleaner and easier to understand. Guess there could be a pretty even split in opinions on here about it. Maybe time for a The hidden cost of Java thread ... er, actually, screw that - we've had about 6 threads on here in recent memory that could have had that title!

@kaffiene - can you honesty say that you truly understood the equation in less than a second? If so, both you and Sickan and way more clever than me and the vast majority of programmers on the planet. Its not about trouble...it's about read/write/maintainability.@Oskuro - Forget c++.@princec - no matter how you slice it, it's awful.

Like with String magic overload of +, the mathematical operators could just magically work on Double, Long, AtomicLong, Integer etc. No need to declare anything at the Number level.

Also the compiler could be clever enough to use primitives to avoid the boxing overhead and aid performance. Again magic, but there already is magic hardcoded stuff like this in the jvm.

I mentioned it on another thread. It would be great to have a Concatable<T> interface. Let List<T> implement Concatable<List<T>>, for example. ! or [] probably would be good, too. Arithmetic operators are a little more troublesome.

There's no confusion that string + 5 is a different type of operation than number + 5. (Given you have the variable declaration or you can infer it based on whether you see function calls or -, *, /, or % operators operating on the variable nearby.) There is also no confusion that one returns a reference to a new object and one uses by value assignment semantics. Without adding a new type of type, then retrofitting classes to support arithmetic operator overloading is less effective.

If so, both you and Sickan and way more clever than me and the vast majority of programmers on the planet. Its not about trouble...it's about read/write/maintainability.

In my experience working with C++, enhancing maintainability or increasing readabilty was not what operator overloading does. Actually, that was pretty much of the point of the original article - you look at the code and think it does X where it actually does Y because in this case the meaning of the operators has all changed.

Obviously you have different intuitions about readability, that's cool. I have a lot of experience of using C++ that shows operator overloading being a maintenance nightmare. That doesn't mean that a language couldn't do it better, I suppose.

If you only look at languages like C++ and Perl to decide if a given language feature is good or not...you'll quickly decide that assem is king. Forget shit designed languages...esp if they are semi-popular. They might be practical/pragmatic to use at some point in time, but that's it.

The question becomes just how much longer does not have operators cost you. By far the most expensive resource is your time.

And code readability, specially in a development team, has a massive impact on time.

In my opinion, it is always a balancing act between performance and development goals (aka deadlines). And the positive side of structured readable code is that you can always optimize bottlenecks afterwards.

The again, if you go crazy with overloading things can get worse very quickly... So... Code responsibly?

My problem with operator overloading is operator behavior. There are 2 main aspects to that. Mathematical behavior and well "instance" behavior.

Mathematical is perhaps the biggest. If i have a field with + and * that is also commutative then well we are fine. However this is a pretty small set of types where this makes sense. Even matrices don't fit that, and so you are forced to add more meaning onto overloaded operators than the originals have. (ie can't reorder the same way)

The next is also problematic. a+b means we need to copy a then add b to a. Otherwise everything gets screwed for larger statements. say (a+b)*b+a*c for example. This is what happens in C++ IIRC, and can end up really slow with the large amounts of bit wise copies that the compiler can't eliminate. In java the copy would need to be well defined (deep enough) to not interfere with operator overloading.

Having written things for GF(2^m) and Z_p in java, where we do fit the math behaviors of +*. Operator overloading would have been useless for creating anything that had decent performance.

I have no special talents. I am only passionately curious.--Albert Einstein

Devil's advocate mode: We can agree that floats are not R and 2's comp integers are not Z. And that many properties/identities of R and Z do not hold for their computer equivalent. There is no special operators to indicate, for instance, that add/sub/mul in floats are not associative nor integers wrapping/modulo properties. I have no problem with that. Likewise for non-commutative products...don't have a problem with it being represented by the same token as one that commutes over some other type. All of this boils down to if you don't understand the type, then you really can't understand the operations anyway.

WRT: compilers and transforms...I'm too lazy to comment ATM. Esp since we all know this is just blah, blah, blah.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org