Well. It really depends what do you mean by ,,better''. I consider the
lack of operator overloading an advantage because it helps to understand
the code. Also, operator overloading is frequently abused making it very
difficult to analyze the code.
No. This is simply FUD and nothing more.
Operator overloading was abused widely in C++; it was abused by the guys
who designed the standard library (the great Bjarne himself?), and that
set an example that led to it being abused by other programmers. Smalltalk
has operator overloading, and it isn't abused there. Python has operator
overloading, and it isn't abused there either. I can show you any number
of languages with operator overloading where it isn't abused. There is
nothing inherent about operator overloading that leads to abuse - the
problem in C++ is a cultural one, not technical.
Java's designers made the argument you made, and many even have believed
it, but all this means is that they're traumatised C++ survivors, not that
they're right.
It is not only about reading the code. Think of all the great tools like
IntelliJ IDEA. They exist only because Java is quite easy to analyze
statically. While operator overloading would not prevent static analysis
it would certainly make it harder.
No, it would make absolutely no difference whatsoever. The syntax already
includes operators, and dealing with operators as method calls just
means treating "+" as a method name.
Think that it will make cost of creating good tools higher which means
less tools for higher price.
Think of all the people that have to learn Java. With time, Java
Language Specification gets longer and longer as it incorporates more
and more features. While it may be easy for you to learn new features
for the new release, people starting with Java have to learn it all
which gets increasingly harder.
They already learn how to use operators on primitives (and Strings), so
that wouldn't be an additional burden for using them on objects.
I doubt very much that learning to write overloaded operators would be
very difficult - in other languages, they're just like normal method
declarations, but with a magic word, so we might see:
// C++ style
public Point operator +(Point p) {
return new Point((x + p.x), (y + p.y)) ;
}
// python style
public Point __add__(Point p) {
return new Point((x + p.x), (y + p.y)) ;
}
// Smalltalk style
public Point +(Point p) {
return new Point((x + p.x), (y + p.y)) ;
}
// let's use the hash sign for something!
public Point #add(Point p) {
return new Point((x + p.x), (y + p.y)) ;
}
// maybe something with annotations
@operator(symbol="+")
public Point add(Point p) {
return new Point((x + p.x), (y + p.y)) ;
}
In any case, if you think it is too hard, just leave it for an advanced
chapter. There's no huge need to teach people to write overloaded
operators right at the start. In fact, it might be better not to!
In mine opninion things like closures only pollute language while not
helping anything that couldn't be addressed without them.
Oh, surely you're kidding me? I take it this means you've never used a
language with closures? One of the best things about python, one of the
things that meant i never looked back when i switched to it from java, was
the existence of lambda expressions, functions as first-class objects, and
higher-order functions.
Then think that when anything is included into Java we're stuck with it
FOR LIFE or until we change the language for something different.
Yes. And both closures and operator overloading are features which are
well-enough understood in other languages that there is essentially no
risk in adopting them in java.
Isn't it much for changing
Time t3 = Time.add(t, t2);
to
Time t3 = t + t2;
?
For your next exercise, try some matrix algebra with and without operator
overloading.
tom
