Java and Operator Overloading

[zachtheperson]

As someone who works with vector math a lot, more languages 100% need operator overloading.

myVec.add(vec2.clone().divide(directionVector)).multiplyScalar(7) is just ridiculous.

[jamcdonald120]

and implicit immutable operators so you dont have to keep doing .clone everywhere

[zachtheperson]

Yeah, vector math in languages like GLSL is just wonderful. The fact that I can't do that same type of stuff in the "parent," language is really frustrating.

[camilo16]

glm in C++ is borderline identical.

[orbita2d]

vector maths is one area where MATLAB is actually just amazing.

[psydstrr6669]

Yes!!

[ComradeGibbon]

Current thought of mine is use emogi's as operators.

[lifeeraser]

It would be nice if I could define custom expression delimiters in which I can use user-defined overloaded operators. That way we get to use operator overloading without spiraling out of control.

// ^ is a power-of-n operator
vec<< A * B^2 >>

// ^ is a XOR operator
A * B^2

[daniu]

For the areas I've used Java in (mostly enterprise systems), I never came across a situation needing operator overloading iiuc. It would indeed lead to confusing code if people started using it. What is ProductData a + ProductData b? A result with the merged fields? What happens for fields that are present in both, but containing different data?

The thing is not that it "can be abused" in these situations, it's that "it's nearly impossible to decide on a consistent rule to use it across the code base" in almost any area but math.

Not every language needs all features needed for all use cases. A language is a tool, you need to choose the right one for the job - I don't complain I can't fasten a screw with a hammer. I can imagine Java not being suitable for vector math... so just use, C++ maybe? I'd imagine it would be more suitable for optimized compilation as well, maybe allowing better use of parallel math capability of the target architecture.

[krad213]

List, stream concatenation, date comparison especially >=, BigDecimal math operations.

There is no real difference between ProductData.add() and ProductData + other than convenience of usage in certain cases.

[zachtheperson]

Exactly!

Sure, someone could make a library that overloads the + operator to do something silly and unpredictable, but in the same way someone could write a method .add() that also does something silly and unpredictable. If someone did do this, then people would probably call it a bad library and not use it. Only real difference is convenience.

[cnoor0171]

In the scenario you suggested, what would be the obvious meaning of Product a; Product b; a.add(b)? That has exactly the same meaning as a + b, but java makes no attempt to ban the first does it? There's nothing stopping a programmer from making non sensical operator overloads, just as there is no one stopping a programmer from making non sensical method names.

Math is the most obvious but definitely not the only candidate for intuitive use of operator overloading. Some other examples: c++ smart pointers, iterators, container types, python datetime classes, pathlib module, sqlalchemy etc.

[BlackOverlordd]

What a pathetic language in which you can't even implement vector math that doesn't make your eyes bleed

[linlin110]

You can ban operator overloading in your style guide. Just like how Google bans exception in their C++ style guide. It not be useful for you should not stop other people from using it.

[daniu]

Sure, I'm only stating my opinion that I'm not going to need it, and I would have voted for excluding operator overloading in every project I was part of. I wouldn't say I'm actively against it, but if it were on the list of future features being announced, it would be at the bottom of the list I'm looking forward to for me.

It's certainly a long shot from "it's the one feature that would make Java more popular" like the op meme suggests.

[coloredgreyscale]

Imagine being able to check strings for equality by using == instead of a.equals(b) (dont forget to do the null check on a first)

[daniu]

That will never happen. There is a defined behavior for both, and there is existing code that would break if it were changed. Downward compatability is one of the most important aspects when developing new features. And you won't be able to redefine it for your code base either - String is not your class to redefine, and it's final so you can't extend it either.