Just wondering why Java didn't implement operator overloading as have just converted a quaterion camera from c++ to java and the maths equations in java is just painful. Was there a good reason for leaving out op overloading?

It was a matter of taste. The creators of Java decided that operator overloading can cause a lot more problems than the ones it can fix. And since Java is a language that is supposed to make shooting yourself in the foot as hard as possible, they kept it out.

shmoove

Ican understand that op overload can create problems but, i think they really lost a valuable tool for equations. Of course it can be abused, i just think that its way to useful to just drop, have they ever considered introducing it i wonder, maybe i could send sun an email ;)

Well, it's just syntactic sugar. You can do exactly the same without it, but the code will look different. Hell, you could even write a small preprocessor that can replace "overloaded operator syntax" to regular Java syntax right before compilation if it's that important.

And I'm sure you can send Sun a letter, but you'll probably have some more luck (though not much I wager) by becoming a JCP member and starting a JSR.

shmoove

Quote:Original post by Preacher
Ican understand that op overload can create problems but, i think they really lost a valuable tool for equations.

Nope.

Only if your OOP skill is poor do you need op-overloading.

OR: if you are doing some niche stuff (e.g. financial services work). In that case, however, you SHOULDN'T BE USING JAVA - if what you *really* want is a mathematical language, you should be using a mathematical language, and preferably a pure functional one, and only using java for the non-mathematical bits.

Such niches are very small, so small that Sun decided rather than spite the many to make the few happy they would make the many happy and spite the few. They do have projects underway trying to make statistical analysis people happier with java, and there is lots of ongoing discussion about what changes Sun could introduce to make life easier for people who need more control over the FP operations, for instance. But 3D engines are not included, since they don't need any of this.

For 3D engines, there's no way you need op-overloading. Mainly because op-overloading produces inferior engines: there are too many things you need to do in an engine, and yet only about 6 operations that have stnandard meaning; these are way too insufficient.

For instance, in a 3d engine you need:
- add vector A to B, returning result C, without modifying anything
- ditto, but store result in A
- ditto, but store result in A and normalize it
- any combination of 1 above with 2 or 3 simultaneously

Seeing as each of these creates different numbers of temporary objects, and is used in different algorithms, you really need all of them (sooner or later), but there are only TWO standardized operators for addition: + and +=

And this is a simple case.

Most of the vector algebra you need to do benefits greatly from having the verbosity of words. Please c.f. the discussions in the 1980's and 1990's about whether we should use "long variable names". Most of the arguments in favour of long var names apply to non op-overloading (in addition to the other arugments against op-overloading).

The only time you need op overloading is when you need a mathematical language or you have a crap IDE. Go and get a better IDE with autocomplete. Even VIM can do heuristic autocomplete (i.e. it analyses your code and second-guesses what you probably want to complete, putting that to the first item in the list, so often you don't need to select an item manually).

(PS: I've written 5 software renderers, everything from C scanliners to a 3kb java engine with dynamic lighting. I speak from experience: over the years it's become more and more obvious that op overloading is unnecessary and undesirable in 3D engines)

redmilamber

All good, i must admit i've haven't much experience making game engines its just as i siad my first try at making a quaterion camera was not helped by the fact that having to use methods to add, dot product etc.. vectors confused the matter further. I'm sure i'll get used to it in time and i didn't think of some of the ideas presented. So no to operator overloading then ;)

Quote:Original post by Anonymous Poster

Quote:Original post by Preacher
Ican understand that op overload can create problems but, i think they really lost a valuable tool for equations.

Nope.

Only if your OOP skill is poor do you need op-overloading.

That's not necessarily true. Operator-overloading, while it can cause problems while it's being implemented, can also make code a lot easier to read when they are used. Honestly, which is easier to read?

This:
BigInteger num = a + b - c * d / e;

Or this:
BigInteger num = a.add(b.subtract(c.multiply(d).divide(e)));

True, you can get by without operator-overloading. Even the best OOP programmer would probably agree that the first example above is much easier to read and write, though. Since part of Java's purpose was to be simple and get rid of unnecissary complications, I have to agree with their decision to keep operator-overloading out of the language. However, to an experienced programmer operator-overloading can, when used properly, clarify code and make its meaning clearer. (I guess that's probably one reason why there's more than one programming language. [lol])

Quote:Original post by TheBluMage

Quote:Original post by Anonymous Poster

Quote:Original post by Preacher
Ican understand that op overload can create problems but, i think they really lost a valuable tool for equations.

Nope.

Only if your OOP skill is poor do you need op-overloading.

That's not necessarily true.

I did give one other possibility...

Quote:
Operator-overloading, while it can cause problems while it's being implemented, can also make code a lot easier to read when they are used. Honestly, which is easier to read?

This:
BigInteger num = a + b - c * d / e;

Or this:
BigInteger num = a.add(b.subtract(c.multiply(d).divide(e)));

Ha! You fell into the trap ;) :P. The second one is better, because it has explicit binding. The first one would need to be written:

num = a + (b - (c * d / e) )

in order to be as informative as the second.

Quote:
True, you can get by without operator-overloading. Even the best OOP programmer would probably agree that the first example above is much easier to read and write, though. Since part of Java's purpose was to be simple and get rid of unnecissary complications, I have to agree with their decision to keep operator-overloading out of the language. However, to an experienced programmer operator-overloading can, when used properly, clarify code and make its meaning clearer.

But...you're still talking "theoretically", and ignoring things like the simple fact that:

*

Has 5 standard meanings, just in basic programming, just off the top of my head. (multiply, cross-product, any-char, any-char-except-dot, FSM-0-or-more). I'm sure if I sat around all day I could think of 3 or 4 more common meanings.

Even:

+

has plenty of meanings in vector algebra (and even more in general computer science)

e.g. How many of these mean the same thing?

=
==
:=
:==
<=
=<
<

Answer: all of them, if you're writing parsers. Because the "standardization" on the first operator used in grammars is so weak that all the above are used frequently :(. They also mean 6 different things, if you're writing parsers. Confused? You will be...

It's a nice idea to think that the use of simple operators is "easier to read", but it's an idea that any professional programmer ought to soon realise is a pipedream: After more than 2000 years of history, Mathematicians *still* haven't managed to standardize on symbols, and they have a lot more to play with than programmers do. IMHO it is naive to think that a symbol means the same thing to different readers, and it's blatantly not true.

redmilamber

BigInteger num = a.add(b.subtract(c.multiply(d).divide(e)));
(setf num (add a (subtract b (multiply c (divide d e)))))

BTW: "add" is just as ambigous as "+"

[Edited by - Trap on December 16, 2004 7:49:32 AM]

chuckle. Nice try.

Add is in fact less ambiguous than "+", seeing as the latter has standard meanings as diverse as (space), but your point is fair.

However:

1. add can be embellished to addAndStore, addEquals, addNoCopy, addNormalized, etc etc, whilst still clearly being a derivative of the basic add function, whereas embellishment of + to each of those is somewhere between hard and impossible

2. you would choose a better name than add. You don't get much option, comparitively, of "better operators", but your names can be as descriptive as necessary, and it doesn't even require more typing and it doesn't take up more space (if htose things are a concern to you).