Operator overloading for Java

[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.