Re: operator overloading
Tom Anderson wrote:
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:
[ snip styles ]
This is the kind of style I've envisioned myself:
public class Point implements Addable<Point, Point> {
// etc.
public Point add(Point p) {
return new Point((x + p.x), (y + p.y));
}
}
with Addable of course being:
public interface Addable<A,R> {
public R add(A addend);
}
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.
Bloch (I think it was him) had a presentation a while back on why
closures and Java don't mix; I myself was irrevocably convinced that
they were a poor idea when I saw that "return" and "return;" would mean
different things under the BGGA proposal (and then some people arguing
that the differences were "obvious"). Java's a great object-oriented
language; don't try to force it to become a functional one as well.
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.
As Bloch points out in his presentation, there is a high risk. It mixes
with generics and autoboxing in such a way that some things that seem
like they should work just plain don't and can't. There is also the
great chance that you end up with a situation not unlike what happened
with generics: it goes only halfway and you end up with some aggravating
problems.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth