Coming from C++ to Java, the obvious unanswered question is why didn't Java include operator overloading?
Isn't Complex a, b, c; a = b + c;
much simpler than Complex a, b, c; a = b.add(c);
?
Is there a known reason for this, valid arguments for not allowing operator overloading? Is the reason arbitrary, or lost to time?
Technically, there is operator overloading in every programming language that can deal with different types of numbers, e.g. integer and real numbers. Explanation: The term overloading means that there are simply several implementations for one function. In most programming languages different implementations are provided for the operator +, one for integers, one for reals, this is called operator overloading.
Now, many people find it strange that Java has operator overloading for the operator + for adding strings together, and from a mathematical standpoint this would be strange indeed, but seen from a programming language's developer's standpoint, there is nothing wrong with adding builtin operator overloading for the operator + for other classes e.g. String. However, most people agree that once you add builtin overloading for + for String, then it is generally a good idea to provide this functionality for the developer as well.
A completely disagree with the fallacy that operator overloading obfuscates code, as this is left for the developer to decide. This is naïve to think, and to be quite honest, it is getting old.
+1 for adding operator overloading in Java 8.
Assuming you wanted to overwrite the previous value of the object referred to by
a
, then a member function would have to be invoked.In C++, this expression tells the compiler to create three (3) objects on the stack, perform addition, and copy the resultant value from the temporary object into the existing object
a
.However, in Java,
operator=
doesn't perform value copy for reference types, and users can only create new reference types, not value types. So for a user-defined type namedComplex
, assignment means to copy a reference to an existing value.Consider instead:
In C++, this copies the value, so the comparison will result not-equal. In Java,
operator=
performs reference copy, soa
andb
are now referring to the same value. As a result, the comparison will produce 'equal', since the object will compare equal to itself.The difference between copies and references only adds to the confusion of operator overloading. As @Sebastian mentioned, Java and C# both have to deal with value and reference equality separately --
operator+
would likely deal with values and objects, butoperator=
is already implemented to deal with references.In C++, you should only be dealing with one kind of comparison at a time, so it can be less confusing. For example, on
Complex
,operator=
andoperator==
are both working on values -- copying values and comparing values respectively.James Gosling likened designing Java to the following:
You can read the context of the quote here
Basically operator overloading is great for a class that models some kind of point, currency or complex number. But after that you start running out of examples fast.
Another factor was the abuse of the feature in C++ by developers overloading operators like '&&', '||', the cast operators and of course 'new'. The complexity resulting from combining this with pass by value and exceptions is well covered in the Exceptional C++ book.
I think this may have been a conscious design choice to force developers to create functions whose names clearly communicate their intentions. In C++ developers would overload operators with functionality that would often have no relation to the commonly accepted nature of the given operator, making it nearly impossible to determine what a piece of code does without looking at the definition of the operator.
The Java designers decided that operator overloading was more trouble than it was worth. Simple as that.
In a language where every object variable is actually a reference, operator overloading gets the additional hazard of being quite illogical - to a C++ programmer at least. Compare the situation with C#'s == operator overloading and
Object.Equals
andObject.ReferenceEquals
(or whatever it's called).Well you can really shoot yourself in the foot with operator overloading. It's like with pointers people make stupid mistakes with them and so it was decided to take the scissors away.
At least I think that's the reason. I'm on your side anyway. :)