Skip to main content

Where should operator overloading be permitted in Java?

Anywhere
23% (199 votes)
Only for math functions on numeric classes
15% (135 votes)
Only in java.* and javax.* packages
5% (44 votes)
Nowhere
57% (496 votes)
Total votes: 874

Comments

No magic please

If there is one big thing I always liked about Java in contrast to C++, perl, or shell scripts it's that there were no "magical statements" of some cryptic form which's effect you could not easily tell by reading the source. Of course, this has been broken by the introduction of Generics in 1.5 (automatic bridge methods can break your old code when compiling with Java 1.5 -scandal!) For this reason, I'ld prefere to better not have operator overloading.

No magic please

If there is one big thing I always liked about Java in contrast to C++, perl, or shell scripts it's that there were no "magical statements" of some cryptic form which's effect you could not easily tell by reading the source. Of course, this has been broken by the introduction of Generics in 1.5 (automatic bridge methods can break your old code when compiling with Java 1.5 -scandal!) For this reason, I'ld prefere to better not have operator overloading.

the other "java"

there's already a version of Java that does operator overloading, stack allocation, pointer arithmetic, unsafe code in general, multiple inheritance, unchecked exceptions, etc..

It's called C++. If you want C++ use C++.. otherwise use Java.

the other "java"

okaaaaaaay....so would you reply in a similar fashion to any suggestion to a change in the Java language. If it's good for Java (surely that is the question), what's wrong with that?

the other "java"

Hmmm... actually.. yes! I would reply in similar fashion.

Java was designed with a certain philosophy. To violate the language's philosophy only makes it messy. I believe Java's strength was to be a "cleaner C++". To add C++ features (especially this late in the game) only makes it messy.

I believe in the "less is more" philosophy. If you want something else add it to the library. Since Java initially came out with no operator overloading.. we're all used to it anyways, then why add it this late in the game. It's also only useful for a handful of mathematical classes. We'll survive w/o it.

A bigger danger is to have to deal w/ messy ++ iterators and junk like that, that ex-C++ developers will love to add to their libraries and make our code as unreadable as STL.

hmm...not convinced

> Operator Overloading would break more contracts of simplicity, beauty and safety of the Java Language that it is not worth the convenience gained. As far as simplicity and beauty go, I think Java lost it when it had botched 1.5 cosmetic surgery. I don't see why it would threaten the safety of language since the operators would ultimately be translated into methods. > Also, I don't see why the following code is so unreadable > final Vector v3 = new Vector(v1).addCoordinates(v2); It's ok at this point, but as soon as you get near anything approximating some serious financial calculatations or maths formula it quickly gets unreadable: final Vector v3 = v4.addCoodrinates(v3.multiply(v1.addCoordinates(v2))); rather than: final Vector v3 = v4 + (v3 * (v1 + v2)) Ultimately, I don't buy "somebody could misuse it" argument - you could pick virtually any of Java's features (particularly of the 1.5 variety) and produce some insane code. However, if I'm writing a science or (more commonly) a financial application I don't want someone to say to me that I can't make my code more readable because some twit might write some strange code if we added that language feature.

hmm...not convinced

Ultimately, I don't buy "somebody could misuse it" argument - you could pick virtually any of Java's features (particularly of the 1.5 variety) and produce some insane code.

You could misuse a lot of things. But practical experience suggests people don't habitually abuse most features to produce "insane code". Practical experience with C++ also suggests operator overloading is often misused for cutesy tricks.

It isn't about whether operator overloading could be misused, it is that it is misused. That is not a theoretical question, it is a practical one with real life evidence.

hmm...not convinced

the argument is "people could easily misuse it" - we don't care if some twit (most probably unemployed from the start or by then) misuses any Tiger / Java features, but we need to make sure that people who uses Java be able to produce libraries of codes that are easy to read, maintain and utilise by others.

It violates the TAO

If needed, go do C++

Who Are These People Who Want to Stuff Java Up?

Of course, we all know what Java *really* needs:
Pointer arithmetic.

Stop arguing..

The answer is no.

How about equals == '=='

I guess I don't care much about overloading except that I really think that comparing objects to see if they are the same object is a special case and most of the time people would like '==' to behave like .equals(). How about just make '==' always point at the object's .equals() method? Probably a pretty rough (probably impossible) idea at this point, but it would have been nicer to me.

How about equals == '=='

Well, Id object because == means is this the same object as this object here. equals means do they have logical equality? That's my reading of it. leouser

breaks more than it fixes

Operator Overloading would break more contracts of simplicity, beauty and safety of the Java Language that it is not worth the convenience gained.

I'm curious though, that so far I haven't heard about people proposing alternative means to achieve the same or similar convenience provided by this over-debated language feature.

Why not?

I've never understood what people's objections to operator overloading. For some domains it makes the code look so much nicer: [code] final Vector v1 = ...; final Vector v2 = ...; final Vector v3 = v1 + v2; [/code] Sure, you can do silly things with operator overloading, but you can do silly things with any of Java's language features. Excluding it just on that basis isn't a good enough reason.

Why not?

The reason is that only extremely narrow-minded mathematicians think that operational relations between entitiesare unambigious. [code] final Vector v3 = v1 + v2; [/code] Now, what does '+' mean in this context? Hard to tell, but it is most likely the operation that seemed resonable to the first person that needed to combine the values of two Vector instances for some reason. Why do you think your need to combine values from two Vectors is the same as his? Also, I don't see why the following code is so unreadable [code] final Vector v3 = v1.plus(v2); [/code] or perhaps this [code] final Vector v3 = new Vector(v1).addCoordinates(v2); [/code] is what you intend to express?

Why not?

Since a Vector is basically a faster more thread safe version of an ArrayList, the logical thing would be for + to mean concatenation. We already have a precedent for this, where when slapping Strings together + is a shortcut for concatenation.

So 'Vector v3 = v1 + v2' would mean create a new Vector consisting of firstly all the objects in v1 and secondly all the objects in v2.

This might be a problem if v1 and v2 contained different types of objects, (hmmm... generics...). Also it is not clear what the - operation would do.

You could extend that to all the collections. Of course, for the ones that implement the Set interface, the meaning would have to be slightly different. + would be the union of the two sets, - might be the intersection of the two?

NB: yes, I do know that you were actually talking about matrix arithmetic :D

No overloading, but short operator names

So, what's the big gripe w/no operator overloading? "multiply" vs. "*" "divide" vs "/" so, why not short names? div mult dot add sub mod cross intg diff I know, it'sa gross hack, but op overloading seems such overkill for this complaint of too-long method names. John (what, no preview button? here goes....)

Nice to have.

It is a plus when dealing with many math ops (i.e: 3d vector manipulation). Of course it can be done without, but having it available for those who would like to use it is nice. Also the age old counter-argument to "we have to maintain someone else's code" doesn't work. If one gets paid to maintain someone else's code, then thats their job, if they don't like it, they're free to find another one. If majority of Java users prefer it, then why not. If its the minority, then whether one likes it or not, nothing will change.

Nice to have.

Also the age old counter-argument to "we have to maintain someone else's code" doesn't work. If one gets paid to maintain someone else's code, then thats their job, if they don't like it, they're free to find another one.

I beg to differ.

If someone is trying to break the primary tools of my trade, I think I have the right to offer a differing opninion rather than automatically resigning my job.

"I have to maintain code that uses bad features" and "years of practical experience shows this feature is often used for creating bogus APIs" are perfectly valid arguments.

Why not?

> Sure, you can do silly things with operator overloading and that's the reason why it is not included in the java language and it's a good enough reason IMHO... The question is "can we find a way to have in Java the pros of 'operator overloiding' avoiding its misuse"? > For some domains it makes the code look so much nicer Agreed.. and one of this domains is the financial domain, something that can't be simply overlooked, considered that Java has gained a solid role in the enterprise. Only, there are domains in which "operation overloading" is not useful and could degenerate easily.. if we could allow "operator overloading" only in the correct domains (that's the reason of the [b] option in the poll) maybe it could be a welcome addition.

Re: Why not?

The lack of operator overloading in java severly restricts the use of the language in any scientific application. Any significant equation is going to be unreadable using methods. There was at least one good example given above but I have code containing equations far more complicated that would be nearly impossible to implement in a readable fashion in java.

I think that the developers of the language, and many of the respondants on this thread, are under the mistaken impression that it is the responsibility of a programming language to prevent developers from doing something stupid. This is the developers responsibility and should be enforce through peer reviews, not by restricting the capabilities of the language.

I will provide two examples of the necesity of operator overloading. One, the ==, <= and >= operators on any floating point type are completely useless without it. Even the limitations of precision in a floating point processor require that some tolerance be used for these operators but more than that the individual application requires that a configurable tolerance be provided. Any numeric representation of a physical quantity is only as accurate as you can measure it and only the developer knows what that accuracy is. Granted, one could implement a withinTolerance method but the operators are, IMHO more convinient and easier to read.

The second example is a physics library. I have written one in C++ which, unfortunatly, can not be ported to java without great pain. The idea is that you can, for example, divide a distance by a time and produce a velocity. The classes internally maintain units and ensure consistency. There are many complex equations involving these classes that would be completely unreadable if operator overloading were not available.

My opinion is that the language should provide developers with the tools that make thier lives easier and it is the developers responsibility to exersise appropriate restraint in using these tools.