finalPos = p1.multiplyWithScal(g1);
In C++, the same code would simply be something like this:
finalPos = (p1*g1 + p2*g2 + t1*g3 + t2*g4);
The code is only working with 3D vectors and scalars, but there are also similar parts for matrices, 2d vectors, lines, quaternions and others in there.
Code like this is distributed trough the whole code base, making these parts totally unreadable. I'm used to write a comment above such lines, showing how the code would look like if the language would support operator overloading, which explains what the code does. And makes it obvious that operator overloading would be quite useful in that language.
So if you are designing a new programming language, think about adding operator overloading for us poor programmers having to work with all this math stuff. :)
twelve comments, already:
You could shorten this to something like
finalPos.addScaled( p2, g2 );
finalPos.addScaled( t1, g3 );
finalPos.addScaled( t2, g4 );
(which is what I do in C++ as well because it’s more efficient most of the time)
Julien Koenen () - 20 05 09 - 16:50
Or you just don’t use any operators other than = at all so noone has anything to cry about.
Ico - 20 05 09 - 16:57
While i can understand this design decision for Java (at least a tiny bit), for ActionScript it feels pretty pointless, given that you are (usually) doing animations and so quite likely have to do something to vectors, like scaling them, lerping or whatever. So while maybe the possibility to create operators for new types is unnecessary, at least built-in vector and matrix types might have made sense…
By the way: Unless code proved to be performance critical I rather have it readable and leave it to the compiler to make it efficient…
xaos - 20 05 09 - 17:04
I prefer operator overloading, too. Especially since adding or multiplying vectors and matrices are well-defined mathematical operations.
However, I see the other side as well. Really, where else does it make much sense?
Unfortunately, some people tend to use a tool if they have it, no matter if it makes sense or not. And if I see ONE more stack implementation that you add elements to with a += operator, I will scream.
Tazo - 20 05 09 - 23:36
No, the former is clearer actually, I don’t have to go to the class definition to get an idea of what the operator is doing.
Jorge - 22 05 09 - 02:36
This days nobody seems to pay attention to readable code :(
Rogvarok () (link) - 22 05 09 - 03:36
Yes you do. Or do you know what the method is doing without reading its doc?
Adding and multiplying vectors are mathematical operations. Of course the operator could do something else than the expected mathemtical operation, but then, so could the method.
Tazo - 22 05 09 - 12:21
Really? I think this is a very contrived example anyway, What about the g’s not being scalars? does it means Dot or cross product? But then again, this is some of those cases where you wither like the feature or you just don’t.
Jorge - 23 05 09 - 00:40
vector * scalar = vector
vector * vector = dotProduct
vector % vector = crossProduct
Just as it is in mathematics, where you write a · b for dot product and a x b for cross product.
Tazo - 23 05 09 - 02:33
I absolutely love this blog software eating your posts when it contains special characters.
I meant to write:
vector * scalar = vector
vector * vector = dot product
vector % vector = cross product
Thats how it has been done in every language where operator overloading is possible, just as it is in mathematics, where a (dot) b is dot product and a x b is cross product.
I agree that you can do some pretty bad stuff with operator overloading, where methods would be much more clear and readable. However, vectors and matrices are one of the few examples where that is NOT the case, as this is where there are exactly those defined mathematical operations.
Tazo - 23 05 09 - 02:36
Tazo, that looks wrong. vector * vector should just multiply each component of the vectors in parallel and output a vector. Incase you want some evidence just look at HLSL, GLSL and the Irrlicht vector3df and vector2df classes (And a billion other vector implementations in C++). In all these cases dot and cross are just performed using ordinary functions.
If someone really did perform a dot product for vector * vector, that would be a very good arguement against the use of operator overloading.
BlindSide () - 25 05 09 - 14:51
At best it is a very good argument against misusing operators, but anything can be misused.
Everyone should stay the hell away from operator overloading if he is writing something that is not the mathematical operation associated with this operator. Vector times vector equals scalar, namely the dot product. Implementing scaling is a misuse of operator overloading, and the fact that many implementations (including Irrlicht) do it does not change the fact that it is a misuse.
To sum it up, here are my rules for operator overloading:
1) Don’t do it.
2) No seriously, don’t do it.
3) You still here?
4) Allright, but do it only if you are mirroring exactly the mathematical operation associated with this operator. Otherwise you are sacrificing speaking code for short code.
I still do not agree that languages simply should not put it in.
Tazo - 26 05 09 - 11:17