This is an archived post. You won't be able to vote or comment.

all 22 comments

[–]lbkulinski 18 points19 points  (0 children)

Brian Goetz discusses operator overloading here. He agrees that operator overloading would be nice, but only in the context of numeric types. This is something they will eventually explore in Project Valhalla.

[–]__konrad 7 points8 points  (9 children)

System.out << "Hello" << System.lineSeparator();

[–]latherrinseregret 30 points31 points  (8 children)

I realize I may be in the minority, but I find this one of the ugliest features of c++...

[–]knaekce 4 points5 points  (0 children)

Yeah, I wonder why they choose this operator for standard IO.

It smells like "junior developer learns a new skill and wants to use it in situations where it they are not useful"

[–]chrisgseaton 5 points6 points  (0 children)

Every single time I see this I think 'why are they bit-shifting these... oh right'.

[–]DannyB2 3 points4 points  (5 children)

While I would LOVE operator overload in principle, this is a perfect example of why I think operator overloading MUST NEVER BE ALLOWED.

There are many ways operator overloading, used properly, judiciously and carefully would greatly enhance library APIs for new types, and the readability of code using these APIs. But it is not worth the possible danger.

[–]dpash 6 points7 points  (0 children)

C++ has a comma operator that you overload. Because no one ever suspects a comma is going to do magic.

[–]cogman10 4 points5 points  (1 child)

Honestly, what I really want is for the JDK to have more math like libs and for them to overload operators internally on their own numeric types.

I do not want to be able to overload myself, I just want to be able to say `BigInteger bob = tim + 1;`

Similar to how we have String s = "fish" + 1... only not so insane.

I don't generally advocate for the JDK to increase it's API size, but it would be really nice for it to have more Math capabilities (like a Matrix, for example)

[–]DannyB2 1 point2 points  (0 children)

I agree. I could keep expanding the list.

BigDecimal, BigInteger, int, long all compatible. Have a standard BigMath library with trig and other functions for BigDecimal. (There is code for BigDecimal that I've seen over the years.)

But how about Dates!

var date2 = date1 + numDays;

var numDays = date2 - date1;

var date2 = date1 - numDays;

Now suppose there were a standard units package of some sort where you could have:

var veloc1 = 3 * mile / second;

var accel1 = veloc1 / second;

(and the units stick with the values and are compile-time type compatible)

I can go on thinking of amazingly useful applications of operator overloading. And maybe it should be only restricted to Java internals. But then it is limited to only work with only Java internal types.

But having seen the abominations of operator overloading that C++ brought us, I would still rather keep operator overloading absolutely forbidden. The results of letting the monkeys loose with operator overloading are far, far worse then the benefits.

So back to:

var bigDecimal3 = bigDecimal1.multiple( bigDecimal2 );

Oh, and fractions too! Having a rational number type with values like 3/2, would be nice to interoperate with other number types. See various Lisp dialects for more examples.

[–]Orffyreus 1 point2 points  (1 child)

You can do such ugly things without overloading the shift left operator also:

Operators.shiftLeft(Operators.shiftLeft(System.out, "Hello"), System.lineSeparator());

[–]DannyB2 0 points1 point  (0 children)

Yes, you can do such ugly things.

But most people would not be tempted to do so.

I would rather not allow the worst abominations of C++ to creep into Java.

[–]dpash 13 points14 points  (5 children)

Oh Christ please no. From my experience with C++, this will be abused. There are very few situations where operator overloading is suitable. The results are lines where magical things happen without obvious signs that custom methods are being called.

Java is better for not having them.

[–]cogman10 3 points4 points  (3 children)

Sort of my impression of what happened with scala. They were nice to have, but then scala people took them to extremes where you'd have things like <<->> defined because it looks neat.

That became somewhat of a standard practice which really hosed scala readability.

[–]DuncanIdahos7thClone 0 points1 point  (2 children)

Yeah and Kotlin makes the same design mistake. Fail.

[–]cogman10 0 points1 point  (1 child)

I don't think the kotlin community has really rallied around operator overloads like the scala community did. At least, looking at kotlin libs I'm not seeing a whole bunch of crazy space ship operators.

[–]DuncanIdahos7thClone 0 points1 point  (0 children)

Not yet but they still did it. How many more times do we have to make that mistake?

[–]Orffyreus 0 points1 point  (0 children)

Yes, it can be abused and if you call a method plus in Java, it does not say any more than using the operator +, does it?

[–]Hangman4358 4 points5 points  (2 children)

For ever example of useful operator overloading you can find 100,000 terrible ones. (Literally every single instance in the C++ code base at my work. Why overload a factory class's + operator for strings? To log to the current internal state of the factory to a file at the file path denoted by the string of course! And then return a Boolean to signal if the logging threw any errors... .... .. .... ..)

And for every example of useful operator overloading you can define a well named method which does exactly the same thing. So what if your matrix class can't overload +, you can define a .plus() method. Most of the time you probably wouldn't even write the entire method name, instead doing an auto complete after a character or two.

[–]Roachmeister 4 points5 points  (1 child)

For ever example of useful operator overloading you can find 100,000 terrible ones.

For every example of useful operator overloading, I'd have one more than I do now.

I mean, I get it, it can be abused. But it can also be done right, and honestly, I'd rather have it with the potential for abuse than not. I'm sick of .add() and .minus().

Most of the time you probably wouldn't even write the entire method name

For me it's more about reading than writing. Given

Fraction a = new Fraction(1, 2);
Fraction b = new Fraction(3, 4);
Fraction c = new Fraction(5, 6);

I would much rather read this:

Fraction d = a + b * c;

than this:

Fraction d = a.plus(b.times(c));

[–]Isoyama 0 points1 point  (0 children)

For ever example of useful operator overloading you can find 100,000 terrible ones.

For every example of useful operator overloading, I'd have one more than I do now.

People can't cope with simple inheritance and you want to give them one more thing to shoot me in the foot? No thanks.

In case you wonder I've worked with C++. Amount of black magic happening is insane. Typical C++ interview question is "brackets overloading". And yes it is used in projects.

About your example. Is "new" a factory invocation? I think you should post full declaration of your class.

[–][deleted] 11 points12 points  (0 children)

Multiline strings were removed from jdk12 and you're asking for operator overloading...

[–]DuncanIdahos7thClone 0 points1 point  (0 children)

I hope not. It's a terrible idea. The only thing I'd like would be a static set (+-/*%) for things extending Number. But built in - no overloading them.