3 ms·
>but honestly overloading is not something I ever miss. And it was a minefield back in my C++ days. For a lot of things, it's fine. And there certainly are pot
by thfuran 4y ago
>but honestly overloading is not something I ever miss. And it was a minefield back in my C++ days.
For a lot of things, it's fine. And there certainly are potential problems with operator overloading. But the experience of, say, reading/writing, linear algebra code using a C++ library with arithmetic operations on vector and matrix types vs using its java bindings where that's all done through explicit method calls wildly favors C++.
- stickfigure 4y agoIn fairness, that's more or less what I remember (from 20 years ago). Operator overloading in libraries built by incredibly smart people could produce beautiful syntax. Unfortunately, most library builders weren't that smart. Maybe it's better now. As a language feature I can't feel more than ambivalent about operator overloading. Kotlin has it, Java doesn't, I'm ok either way.
- kaba0 4y agoI think Rust’s approach is a good tradeoff. Don’t allow arbitrary operators like haskell/scala (!!< is never gonna be readable), but do give an Addable/Multipliable/etc interface/trait which will define add/multiply, to which the corresponding symbols desugar to. It might even help heal the object-primitive rift in java.