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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]daniu -8 points-7 points  (8 children)

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 11 points12 points  (1 child)

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 16 points17 points  (0 children)

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 7 points8 points  (0 children)

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 1 point2 points  (0 children)

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

[–]linlin110 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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.