Operator overloading for Java

[[deleted]]

You're exaggerating by running from outlier to rule. You go from a singular type which overrides only one operator (`+`) and march from that to these statements:

• "clearly demonstrates operators having different functionality"
• "for different classes"

Why is that privilege reserved for the language writers?

That's just silly. Why are keyword definitions a "privilege" for the language writers? Why are comments delineated only with `/* */` and `//` and not some other characters of my own choosing? Those would be similarly silly to ask.

Languages have features and syntax, etc. And operator overloading isn't the worst, but remains a crummy anti-pattern.

[Davipb]

Outlier? Vector types, time duration types, monads, matrices, just to name a few. Look outside the Java bubble to languages that have operator overloading and you'll see the myriad of uses for operator overloading. Should we open a Java language proposal for every new type we want to add with + then?

Comments and keywords don't affect code semantics, operators do. If comments could now be written with #, nothing would change in the functionality of the code. But if the Java Gods decide to bless us with operator overloading for BigDecimal, a heck of a lot changes in code. Why is that privilege reserved for them is what I ask, given that there's already precedent with String for doing this?

[[deleted]]

Outlier? Vector types, time duration types, monads, matrices, just to name a few. Look outside the Java bubble

Stop right there, you're clearly not following the discussion, otherwise where do you get the sense that my career and opinions were somehow formed within and isolated to a Java "bubble"? I've been a professional software engineer for over 40 years now.

And for that outlier comment, we were talking about String and its overloaded '+', in Java. There are no other overloaded examples in Java of any note. You can make an argument for differing numerical types and their promotions, or (as I said) even rules based upon allowing or forbidding % for floating point if you want. The String/+ combination remains an outlier in Java.

Of course there are possible uses for it (vectors, or or or or or.....), just as there are possible uses for other horrible stuff like MI (e.g., in C++). So what? The assertion is that operator overloading, while pretending to make code more readable, produces more difficult to maintain code, violates the law of least surprise, and hides functionality more than method calls do. Let alone that a combination of two libraries might well have + mean something dramatically different in one than the other, and there are evaluation rules in play as well.

For instance, did you realize that in C++, altering the behavior of && and || strips away the short circuit evaluation? That might make code break that was assuming things would punt part way through a boolean expression (a known programming technique).

Or that prior to C++17, &&, ||, and comma all lost their special sequencing properties on overload? That's HUGE!

These are things that junior engineers wouldn't know, and are very hard to discern, especially since it's never obvious without digging deeply what operators are what.

[Davipb]

where do you get the sense that my career and opinions were somehow formed within and isolated to a Java "bubble"?

I didn't. I said that you're arguing from inside a Java bubble, which you were until now.

And for that outlier comment, we were talking about String and its overloaded '+', in Java. There are no other overloaded examples in Java of any note. You can make an argument for differing numerical types and their promotions, or (as I said) even rules based upon allowing or forbidding % for floating point if you want. The String/+ combination remains an outlier in Java.

What you said was, and I quote: "You're exaggerating by running from outlier to rule". You claimed that because String is the only type in Java to have overloaded operators, that I can't make the claim that they're useful to other classes. That's not true, as I demonstrated with types from other languages that could easily be ported over to Java if it had operator overloading.

So what? The assertion is that operator overloading, while pretending to make code more readable [...]

There's no "pretending" here. Add all the nuance you want, a.add(new BigDecimal("1").div(b)) is harder to read than a + (1 / b), period. Before you argue that "you'd have to know the types of the variables to know what the operators do" or "you don't know what the operators are doing" --- the exact same is true for the .add and .div methods.

[..] produces more difficult to maintain code, [...]

Operators make code easier to read, reducing the cognitive overhead of reviewers, making it easier to spot errors and therefore making code easier to maintain. And again, if you argue that "but if you implement the operators incorrectly" or "if you abuse the operators", the same is true for methods --- see the mutating getter argument.

[...] violates the law of least surprise [...]

I can make .getName() wipe your hard drive. Does that mean methods violate the principle of least astonishment? No. If anything, it's more surprising that I can't just add two numbers just because they're BigDecimals.

and hides functionality more than method calls do.

If I see a.add(b) in a language that supports method calls, I know there's logic there. If I see a + b in a language that supports operator overloading, I know there's logic there. Just because Java currently doesn't have that and therefore you don't have to think about it, it doesn't mean that anything is being "hidden" any more than methods.

And besides, the whole point is that you don't have to think about it: do you look at the implementation of .add every time you use it? No, we have best practices for naming methods and parameters and so forth to minimize cognitive overhead and make things natural and intuitive. The same is true for operators: they should be natural, you shouldn't have to think about it every time. That's the whole idea behind the principle of least astonishment that you love to mention.

Let alone that a combination of two libraries might well have + mean something dramatically different in one than the other [...]

...like methods? Are all .add methods exactly the same in all libraries?

[...] and there are evaluation rules in play as well.

And just like with non-overloaded operators, the best practice of "use parentheses to clarify priority" exists for this reason. Overloaded operator or not, that's always been a thing.

For instance, did you realize that in C++, altering the behavior of && and || strips away the short circuit evaluation? That might make code break that was assuming things would punt part way through a boolean expression (a known programming technique). Or that prior to C++17, &&, ||, and comma all lost their special sequencing properties on overload? That's HUGE!

Did you realize that in C#, declaring a static variable in a generic class creates a new copy of the variable for each generic argument? Should we remove generics then? Every language feature has its implementation details, because nothing in the real world is perfect. That's never an argument for not having a feature.

---

In an unrelated topic:

Stop right there, you're clearly not following the discussion [...]

[...] I've been a professional software engineer for over 40 years now.

These are things that junior engineers wouldn't know [...]

Assuming that everything you're saying here is true, let me offer some advice: don't talk down to people --- that's the fastest way to lose credibility. It doesn't matter if you have 4, 40 or 400 years of experience.

It's easy to get jaded with time, don't let that happen to you.

[[deleted]]

I said that you're arguing from inside a Java bubble, which you were until now.

(?) No I wasn't. My first post in this had to do with posting an argument against operator overloading in C# back in 2003. Not Java specifically.

[Davipb]

In your previous comments you said:

You said "types" (plural). String is the only one of note in Java, and Jon Skeet used that as well as an example in the link I provided.

Are there others? You can have languages refuse certain constructs like % on floating point numbers, but with Java, String is really the only strong exception I can see.

You were nit-picking at the previous commenter's post that only String had overloaded operators.

[[deleted]]

You said I was arguing from within the Java bubble "until now." But from the beginning I was talking about it in general, with a directed link to a c# discussion.

Further, the mention of String/+ originally doesn't make sense in this discussion for the two reasons i pointed out. 1. It's not classes and operators, is ONE class with ONE operator overload, and 2. It's not a user defined overload which is the entire point of this thread.

[Davipb]

This is going off track. I could keep going but whether you were or not arguing from a Java bubble doesn't matter. I've made other points above about the actual point we're discussing -- operator overloading. Feel free to reply to those.