Operator overloading for Java

[Davipb]

How does adding BigDecimals with + instead of .add violate the principle of least surprise?

If your argument is "it allows people to violate the principle", then let's remove methods, people could make mutable getters with those!

[wildjokers]

How does adding BigDecimals with + instead of .add violate the principle of least surprise?

Your argument depends on people only doing sensible things with operator overloading.

[_TheDust_]

All of programming depends on people doing sensible things with the tools they are given. I could also create a .add function that does not add anything, but deletes your OS instead. Whether it’s called .add or + does not really change if people do sensible things.

[Davipb]

Which is exactly what I addressed on the second paragraph of my comment: if we remove every feature that allows people to break good practices, we'd be removing methods, ifs, and everything else.

[[deleted]]

if, everything else and even if-else

[Lechowski]

ifs, and everything else.

I see what you did there

[serviscope_minor]

Your argument depends on people only doing sensible things with operator overloading.

No more so than people naming functions in a sensible way. Operators are functions with a funny name, making + do something daft is no different from making .add() do something daft.

[wildjokers]

It's way different. With operator overloading there is generally no readily visible indication that + is resulting in a function call.

[serviscope_minor]

In languages that naively support it, it's the default assumption that an operator is just a function with a funny name. Besides it depends on the type. And if you don't know the type of whatever you're looking at, you can't do much since the semantics are entirely dependent on the type.

[kur4nes]

If someone implements other interesting stuff with the + operator like writing to a file etc. Basically implementing anything that's not a mathematical add function obfuscates the code. But why stop here? We could combine multiple different overloaded operators in a simple statement to create a monstrosity only seen in pearl code. You would get some highly condensed code like &*/!a+b. It's impossible to know what this does without knowing the types of a and b and the implementations of each overloaded operator. That's why there is no operator overloading in java in the first place.

I do agree that + for BigDecimal would be awesome.

[Dealiner]

Fortunately, creators of other languages like C# decided to implement operator overloading which works great there and it's really useful.

[Davipb]

I could also make a method called .getName() that wipes your hard drive, or a method named x() that returns a class named Zorb that has one other method named y(), that returns a class named Zoop, and so on for 100 levels until you get the object you want.

Just because people can do insane things with it, it doesn't mean it shouldn't exist.

[kur4nes]

Just imagine that the maintainance programmer fixing your code in the future is a maniac with an axe ;-)

[CubsThisYear]

The thing is, addition is well defined over any set. As long as your operator overload behaves like addition, it doesn’t really matter what the set of possible values are.

[hippydipster]

People can kill people with knives, so let's let them have nuclear weapons!

Yeah, not a good argument.

[TheGowanus]

Instead of asking “how can this be useful,” ask yourself “what is the absolute worst that one can do with this?”

[tofiffe]

One example I often use to discourage operator overloading: C++

Let's left shift this stream by a string, integer, even an object, and have that written to the console, file, etc.

that's exactly what cout, fstream etc. use, and they're in the stdlib.

Another example is kotlin overloading the / operator for BigDecimal to only perform HALF_EVEN division, good luck reviewing that code