The way to operator overloading in Java

[Kohlmann]

I know that Operator Overloading is a technique which can be especially differ. Therefore, I would like a discussion of possible drift in that direction right away. Personally, I am rarely a friend about this technology and yet it is from and to situations where it can be real interesting. The basic idea for this implementation was based on a discussion forum java-forum.org. There was a discussion about features that are missing Java and would also this was mentioned. Out of interest I started to implement in my view the only sensible way. present result is a modification for the JDT Core (Eclipse compiler) with a nearly 1000 lines long diff File. More information is needed.!!

[RichiRich]

Implemented the whole thing as pure "compiler magic" is. The compiler checks at compile time whenever it finds an operator, whether the class implements the appropriate interface to the operator found and then cooperate to build the stack structure and methods Invoke and writes it to the bytecode. Because I think an appropriate JSR open and submit implementation idea, I would appreciate suggestions and comments about the idea. Unfortunately I could not leave with the idea on the Eclipse JDT compiler mailing list to pay the required discussion. If interested, I could of course also provide the compiler Diff JDT compiler for the current source.

[Timothi]

First of all thank you for your reply and I am particularly happy that this is just almost from the first row. In contrast to the identified "solution" and the proposal of Project Coin has in my opinion after several disadvantages:

• No object oriented design
• Problems with derivatives and composition
• Difficult to implement
• Not type safe
• Theoretically, I can annotate each method with the annotation and the compiler must check whether it meets the required method signature.

Otherwise, I've apparently under the second link, the comment in the direction of Operator Overloading ignored. And what is their opinion about the general idea?

[StudyBoy]

Ah yes now I have seen it. But basically no rejection of operator overloading, which I had expected more tough, after all, it's with one of the most controversial features of a programming language. However, I still remain at the top already erwähten points which speak for me against the approach of annotations (unless you make another kind of DSL, such as for example, JPA). Now would be interesting to judge or generally hear from others with the approach (or read).

[Adley]

Basically, I built the whole thing first for me, of interest to see how such a thing would be difficult to implement. In general, I have nothing against the C + + syntax, and an additional keyword would be fine, but it is not even needed. In Scala, there are "creative method name", eg they can simply mean +. The compiler could also check the method name accordingly. Whether the interface principle means more paperwork: I do not necessarily, since probably no one works without IDE with code compilation.

[Shell]

As a small point of criticism put, I would, however, that I have ruled in my version of certain operators (shift, comparison and assignment operators) from the front early on to avoid confusion, which in my opinion one of the biggest problems with operator overloading is. Furthermore, would the approach of C + + also allow operators to define their own and if something like this is clearly understood yet?

String foo = new String ("foo") ° new String ("bar");

Since I am left wondering what the operator had never seen before.

[Appaji]

I also see no sense in the creative naming of Scala, and the example should show only a "very funny" way of potential operators overloading. I would not use Unicode characters in Java (although possible). A keyword in Java is indeed still a certain problem. We know how difficult it is a new keyword, such as enum or interface preparations. Otherwise, I am novice operator with the keyword you, quite the opposite is the @ operator annotation from the authoritarian left, especially since there is only compiler Magic (enum as well).

[Deabelos]

In principle, one could of course be the Java way, all the (not yet existing) operators to overload. I have certain operators (eg the Equals operator), I have deliberately omitted, since these already fixed meanings. For example, a string == string uniquely checking for instance equality rather than equality of the text. If you suddenly an operator of this type would override (even if it was in this case, the logical alternative) would be moderately code from here on the same errors. Such matters should be excluded directly.

[Viensterrr]

String may always be a "bad" example but it happens to be a fact that the class library will be revised from time to time. I think of the Generics. In principle, the example was "String foo = new String (" foo ") ° new String (" bar ");" bring only intended to as a counter-argument for new operators. In Java, some operators have a specific meaning and if I must now read even in the Javadoc for instance, whether the Equals operator is overridden, or what the self-defined degree operator, then something is definitely wrong. Just as I was thinking that it is non-intuitive if something == causes more than one instance of comparison. Function () and array operators [] are in no way treated as a normal Java operators, since Java defines special opcodes for example, arrays (2 each for each primitive and 2, for referencing data types). Therefore, the Java 7 indicated "Array-like Access To Lists" feature only compiler Magic will be (whether it is also for collections, no idea).