Community
Participate
Working Groups
It is disorienting that the override/implement method dialog box changes the order of the methods to be implemented. The alphabetical ordering may be an option, but definitely *not* the default. The order for override/implement should by default be the order in which the methods and interface/class extend/implement are declared. Example: interface Shape { int getX(); int getY(); int getEdges(); int getArea(); } interface Circle extends Shape { int getR(); } I want to see this when clicking on override/implement methods (aside from formatting): class DefaultCircle implements Circle { public int getX() {} public int getY() {} public int getEdges() {} public int getArea() {} public int getR() {} } I have little or no preference for the below: class DefaultCircle implements Circle { public int getArea() {} public int getEdges() {} public int getR() {} public int getX() {} public int getY() {} } From a readability perspective, the latter is nothing but random order. -Thomas
Only in the outline view and the quick outline we show the actual order. We always sort members in views. So I guess it would be nice to have an option everywhere, but this isn't planed at the moment.
Hi Martin, thanks for your quick answer. What you are saying is beyond the point. I agree that views *can* show methods in sorted order. When I *generate* code, I do *not* (I emphasize not) want my code to be reordered (this is in my editor, not in a view!). Code generation has to use the default method ordering as it shows in my code. If I want reordering, then I want to explicitly say so. This is not a nice to have feature - the current behaviour is just simply not acceptable. I reopened the bug.
Sorry, I understood from the bug request that you meant the order how it is presented in the dialog.
*** Bug 165863 has been marked as a duplicate of this bug. ***
I agree with the bug reporter and want to point out that the same thing also applies for other cases of method generation: "Generate Getters and Setters" should follow the order of the field declarations. "Generate Delegate Methods" should follow the order given in the delegate.
*** Bug 166601 has been marked as a duplicate of this bug. ***
*** Bug 209290 has been marked as a duplicate of this bug. ***
I also agree with the bug reporter. I keep reorganizing the methods after "Add unimplemented methods". In Ganymede this has become easier to do, still I never understood the logic behind alphabetical order within the class instead of the logical method order defined in the interface.
I see that this bug has 'bugday' and 'helpwanted' keywords but is also in state 'assigned'. I'm not sure about its status, but if no one is currently working on it, I'd like to give it a try.
>I see that this bug has 'bugday' and 'helpwanted' keywords but is also in >state 'assigned'. JDT does not participate in the bugday but help is always welcome :-) >I'm not sure about its status, but if no one is currently working on it, >I'd like to give it a try. It's assigned to the inbox. Once we've looked at a bug we assign it to a real owner or the inbox. I've assigned the bug to you. Looking forward to a fix.
Created attachment 140504 [details] proposed patch
(In reply to comment #11) > Created an attachment (id=140504) [details] > proposed patch > Attached is proposed patch. I modified the classes which generate the code and now: "Generate Getters and Setters" follows the order of fields "Generate Delegate Methods" follows the order of fields and methods among single field "Override/Implement Methods" and "Add unimplemented methods" follow the order of methods in source code (the exact ordering is more complicated bacause you can implement methods from more than one supertype at once - it's described in javadoc) I didn't change ui classes - the dialogs for these operations still show methods in alphabetical order. Do you think this should be changed too?
(In reply to comment #12) > > I modified the classes which generate the code and now: > "Generate Getters and Setters" follows the order of fields > "Generate Delegate Methods" follows the order of fields and > methods among single field > "Override/Implement Methods" and "Add unimplemented methods" follow > the order of methods in source code (the exact ordering is more > complicated bacause you can implement methods from more than one > supertype at once - it's described in javadoc) > > I didn't change ui classes - the dialogs for these operations still > show methods in alphabetical order. Do you think this should be > changed too? > It might be nice to show in the UI the order of what is being generated, but as it is in a view, it might be fine to leave it in the alphabetical ordering - I don't have a strong preference either way. I am more than happy to have my code in the editor in the order in which I typed my methods in the interface. Thanks Mateusz for fixing :)
Ok, then I am marking this bug as resolved. Please verify.
>Ok, then I am marking this bug as resolved. Please verify. You should not mark a bug FIXED until it is really fixed in the code - which is not the case here.
(In reply to comment #15) > >Ok, then I am marking this bug as resolved. Please verify. > You should not mark a bug FIXED until it is really fixed in the code - which is > not the case here. > Sorry - I guess I didn't get the process right. So I'm looking forward to a review.
Thanks for the patch. Released with a few fixes: - Used !SourceRange.isAvailable(..) in a few places instead of a null check. - Comparators should return 0 if they don't know what to do (returning -1 breaks general contract of compare(..)). - The change in AddGetterSetterOperation caused a test failure in org.eclipse.jdt.ui.tests.core.source.GenerateGettersSettersTest.test6(), and it didn't respect the "Sort by:" setting from the dialog. Fixed by restructuring the code to look more similar to the old implementation.
- "Generate Getters and Setters" : Verified - "Generate Delegate Methods" : Verified - "Override/Implement Methods" : Verified - "Add unimplemented methods" : In the example above the following code is generated. That is methods from immediate super class comes first and then the methods from super super class. class DefaultCircle implements Circle { public int getR() {} ---> this should be in the end public int getX() {} public int getY() {} public int getEdges() {} public int getArea() {} }
(In reply to comment #18) I think both orders (the one in comment 0 and the one implemented) are reasonable. Unless someone has a strong preference, I'd leave it as it is.
- "Override/Implement Methods" : For this case the super super class method comes first and then super class methods. - "Add unimplemented methods" : Methods from immediate super class comes first and then the methods from super super class. I prefer the implementation for "Override/Implement Methods" case. And I think that both cases should follow the same ordering of methods.
You're right, we should be consistent. Filed bug 297183 for that.
