Just give us operator overloading!
I just came across this post. It looks like there’s talk to introduce special operators for getters and setters in Java 7! The following two lines might be equivalent:
a.setFoo(b.getFoo());
a->Foo = b->Foo;
See page 27 of this PDF.
It’s just so wrong to me. The problem only exists because field access is done by static type, if they did the same lookup as they do for methods, we could just use ‘.’. If you wanted to do something different in a setter or a getter, then you could explicitly write a method.
The suggestions on page 28 make more sense, e.g. String support in switch blocks, and comparison operators for enums. But why not just give us generic support? Why can’t I use any object in a switch statement? Surely it could just invoke equals()? Similarly give me the chance to define what -> means, or add comparison operator support to any class I want. Then I wouldn’t mind stupid things like ->, but this whole, some objects are more equal than others thing when it comes to operators, and stupid operator definitions, that I can’t abide! 
December 12th, 2006 at 4:48 pm
No don’t give us operator overloading, it complicates the language both for the developer and the compiler. No wonder in this day and age that C++ is STILL not portable to many platforms on which the much younger Java runs flawlessly! (without Java 5 features obviously since they are mostly redundant on a cell phone etc.).
I agree the -> feature is stupid but so is overloading which is just a way to make code less readable, people often misuse this feature by breaking the operators semantics and then blame the resulting bugs on the language/library.
December 12th, 2006 at 7:09 pm
Are we still in Kindergarten?
Blocks, operator overloading, etc are neccessary features if you want to play with the adults. Whether Java should support it is a different question. I opt for a Java for idiots as it is now. Remove annotations etc. And, additionally, introduce a JavaPro for ppl who really want to get work done. Introduce blocks, op overloading, make typing optional, etc.
What I’m saying: I understand Shai. ‘Normal’ developers need an easy language. But if you want to support advanced developers, you need to provide them with the right tools.
Anyway, it doesn’t really matter because there are good alternatives. A JavaPro could be very cool. But all we need is good VMs. Because Ruby, Python, Lisp, etc are already - and existing - nice alteratives to a JavaPro.
My two cents..
dl
December 12th, 2006 at 9:07 pm
I didn’t call you a child for expressing an opinion
My dad must have missed the whole discussion about operator overloading when I had my bar-mitzva so I don’t see where they become “adult” features in a language. Especially not where most languages commonly used don’t have them…
I don’t just say that “normal” developers don’t need operator overloading, I’m saying that no one needs it and its not an advanced feature. Its a feature with no real use cases outside of niche uses (vector calculations) in which case using a method would work just as well and be far more readable to all persons involved. I cannot “grep” (and I use the word grep to indicate using the IDE’s search functionality) a usage of “+” and if operators are overloaded it is often hard to tell what is happening in a narrow block of code.
Unlike many language features you could add to Java, operator overloading provides no technical advantage other than hiding “the bare metal” so you don’t see that a method call is being made in order to perform the operation you requested. When dealing with large bodies of code this is hard on the most experienced programmer, I see no advantage other than the: “cool I can use the x operator for my custom object” argument.
About ruby, python and lisp notice several things:
1. Different languages with different audiences - scripting languages tend to target ad hoc development which is great but they are not competitors to Java.
2. Ruby and python are running on top of the Java VM with some technical advantages on their “native” VM. This is supported by Sun and is a part of the concept of one language can’t fit everyone.
3. Everyone is welcome to use the language of his preference but this does not make Ruby less than Java or the other way around, a feature has objective aspects and subjective aspects and language features often are very subjective.
December 13th, 2006 at 8:05 am
Yes to generic support in switch blocks - very useful.
No to operator overloading - if you want it use c++
December 13th, 2006 at 11:06 am
Do I actually want operator overloading in Java? I’m still undecided about that. There are some cases where I’d like it, the overloading of ‘.’ and ‘=’ in Ruby is a much more elegant way to solve the getters and setters issue.
The main issue I have is this partial operator overloading that Sun is doing, is that the classes are part of the standard library, not the language. It started out with String and ‘+’, then we got Iterable and the whole foreach syntax, now they’re talking about <=, >, etc. for enums (but why not classes that implement Comparable?). I can’t implement these things if I was writing things from scratch in Java. I don’t know why, but it bugs me that I can take Java as a language and implement my own set of libraries to go with and make Java ‘Miles’ Edition (not that I’d want to).
Either make these special classes part of the core language, or expose the ability to overload operators in any class, that’s what I want to see.
December 13th, 2006 at 2:12 pm
No. Opertator overloading was left out of java for a very good reason. Namely, because it obfuscates the intention of the code.
What does
Customer a = new Customer();
Customer b = new Customer();
Customer c = a + b;
mean? Who knows?
December 13th, 2006 at 2:23 pm
What does this mean?
Bad code is bad code, no matter what the feature.
December 13th, 2006 at 2:42 pm
It’s even worse than that in C++ where sadistic people can overload ( ) [ ]
Making calls to methods or accessing objects in an array gets really interesting when those symbols no longer mean what they are supposed to mean.
Not having overloading in Java doesn’t hamper me - it helps to protect me from self-described geniuses who like to use every language feature imaginable to make a big mess and then move on to the next project with management expecting me to clean up their mess.
December 13th, 2006 at 3:49 pm
i think a more sensible option is to make operator overloading restricted. for example, allow it for BigDecimal etc (which is coming), or for arrays. there is another idea, but not sure if it is logical.
like defining an interface for operator overloading with allowing usage of +,-,*,/ symbols for sum, multiplication and division contexts. This would cover a lot of basis. Like interface is ArithmeticOperable interface with 4 mandatory methods in it and for those methods you can use operator overloading. Then you can write Vector implemets AritthmeticOperable etc.. but is it open to abuse? yes, but much less then a full blown Operator overloading functionality.