And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool operator overloading is. So there were a ton of overloads everywhere and you couldn't really tell what is just built-in operators and which is our own code. Total nightmare. After this I would be fine with operator overloading removed from languages.
Nothing wrong with writing:
Matrix_Multiply(m1,m2);
vs.
m1*m2
The first is not harder to read and not harder to write but I know exactly what's going on.
So this code is from Go's big.Int documentation (slightly adapted):
func main() {
a := big.NewInt(0)
b := big.NewInt(1)
var limit big.Int
limit.Exp(big.NewInt(10), big.NewInt(99), nil)
for a.Cmp(&limit) < 0 {
a.Add(a, b)
a, b = b, a
}
fmt.Println(a)
}
I can't say I'm particularly keen on having to read
a.Cmp(&limit) < 0
instead of
a < limit
The question is whether it's worth it to write code like this in order to prevent others from misusing operator overloading. I guess it may depend on how much math code you write and how disciplined your coworkers are.
> The first is not harder to read and not harder to write but I know exactly what's going on.
For your example, maybe so. But:
m = a * b * c + d * e + f
will be clearer than three Matrix_Multiply and two Matrix_Add calls. And one screen full of lines like mine will be far clearer than five screens full of Matrix_Add and Matrix_Multiply calls.
Nothing wrong with writing:
Matrix_Multiply(m1,m2);
vs.
m1*m2
The first is not harder to read and not harder to write but I know exactly what's going on.