Community
Participate
Working Groups
Operator overloading does not look like it will be making its way into the Java platform anytime soon. This means that financial math involving BigDecimal tends to look rather messy compared to what it might look like if operator overloading was available. I think Eclipse has an opportunity to help the comprehension of programs by providing alternate representations for Java code, syntactical sugar if you will. Eclipse could identify sections of code that might be more clearly understood with an alternate representation, and then provide a means for users to switch that chunk to the alternate form. At all times the actual text written to disk would be the *canonical Java form*. The user could potentially edit the code in the alternate form and then know that the correct Java form was written to disk, toggling back and forth to understand the relation between what they see and what they get. For example, the user might see: a * b - c rather than a.multiply(b).minus(c) So how would Eclipse know that BigDecimal.multiply is the "*" operator? Metadata, either Java 5.0 annotations, or in the case of system classes, seperate annotation data. One of the tough things about C++ operator overloading is that it is hard to look at the code and understand what overloaded operators are called and with what precedence -- i.e. the actual behavior can remain hidden. This feature aims to tackle that by saying that the actual code on disk is the real deal -- exactly what will run in canonical Java. It's just the representation in the editor that can be toggled to show the alternate viewing/editing form which may simplify the comprehension for the reader. Anyways, just thought I'd share this idea. Thanks for making such a great IDE.
This also affects Compare and eventually formatting i.e. would the alternate representation be formatted.
Get rid of deprecated state.
Created attachment 131550 [details] a simple operator overload test result
Created attachment 131551 [details] oo simple implementation At beginning, I want to employ CompilationPariticipant to handle. After coding, I found I not want rewrite to source code of editor, and don't know how to apply change to jdt dom AST. So redoing it from parser, get this way. Another issue, List list; list+"abc" jdt recog to a single assignment expression, and no other info, I not think it as good way. Maybe someone have interest to talk this:)
I can't see any effect in the editor when using your patch.
Comment on attachment 131550 [details] a simple operator overload test result I make a wrong choice for the picture
Created attachment 131752 [details] relative to the text patch effect should be this picture
(In reply to comment #5) > I can't see any effect in the editor when using your patch. > the patch is my first try, you should pass compilation of the binaryExpression of assignment expression. After this, I added tries for method argument and combine binar expression, and the assignment. more details, please see http://code.google.com/p/oo-jdt or the lastest patch I also attatched
>or the lastest patch I also attatched Can't see it here.
Created attachment 131756 [details] operator overload patch for jdt.core.compiler.ast the patch added method argument, combined binaryexpression, and this single assignment which jdt report Syntax error. More, the operator overload built on jdt normal process, so default syntax the patch not add any additional behavor, f.e. list+ "abc" + 3 jdt handle "abc"+3 success so the patch just resolve: list + a(=["abc"+3]) so the list item should be "abc3"
(In reply to comment #9) > >or the lastest patch I also attatched > Can't see it here. > Right I uploaded it. Indeed, my now workspace used it. BTW, I log it at http://www.jroller.com/qinxianscript and I sure it's some kind of reason this blog:// http://www.dzone.com/links/why_java_doesnt_need_operator_overloading_and_ver.html hahaha
Sorry, I still can't see a difference in the editor. Do you have an example that would show me what your patch does?
(In reply to comment #10) > Created an attachment (id=131756) [details] > operator overload patch for jdt.core.compiler.ast It looks like your patch is changing the AST, which is a definite no-go (we cannot invent our own Java dialect). The intention of this bug is to only modify the representation in the editor (not the file on disk, etc.). But to be honest, I doubt that this is feasible without major changes to the Java editor, since all code that deals with offsets would have to take the modifications into account.
(In reply to comment #12) > Sorry, I still can't see a difference in the editor. Do you have an example > that would show me what your patch does? > Yes, there is a jar http://oo-jdt.googlecode.com/files/org.eclipse.jdt.core_3.5.0.v_946.jar the binary show: BigInteger a, b; a=a+b; it not handle assignment and combine binary expression. there is screenshot: http://oo-jdt.googlecode.com/files/operatoroverload2.jpg or http://code.google.com/p/oo-jdt/
(In reply to comment #13) > (In reply to comment #10) > > Created an attachment (id=131756) [details] [details] > > operator overload patch for jdt.core.compiler.ast > > It looks like your patch is changing the AST, which is a definite no-go (we > cannot invent our own Java dialect). > Yes, the way do changed AST. the main idea just try the aproach: When InvalidOperator problem or ParsingErrorInvalidToken(InvalidAssignment) error, just try to MessageSend resolve. > The intention of this bug is to only modify the representation in the editor > (not the file on disk, etc.). But to be honest, I doubt that this is feasible > without major changes to the Java editor, since all code that deals with > offsets would have to take the modifications into account. > Yes, the way diff from the intention of this bug. through, the offsets do in account.
