| Summary: | Override methods does not alphabetize inserted methods. [code manipulation] | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Randy Hudson <hudsonr> |
| Component: | UI | Assignee: | Erich Gamma <erich_gamma> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | Keywords: | helpwanted |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Randy Hudson
There are plans under investigation to provide - a formatter that sorts methods - dnd in outliner to rearrange members There are no plans to alphabetize inserted methods since other users would like to see other insert strategies (for example a getter together with a setter). Tagged as help wanted. People requesting other sorting methods are wrong. Alphabetized sorting of methods is the standard. It is the only sorting recognized by JavaDOC, and the only sorting recognized by the JDT's outline page. Why has JDT decided to recognize this sorting in the Outline, but not in the code manipulation infrastructure? The current code formatter does not work like I want. I never invoke it because it indents members of the CU's primary Type. See bug 10859. So, this formatter would have to only alphabetize methods, and not mangle whitespace for me to use it. One potential problem would be that inserting methods in various locations in the CU would be hard to find. One solution to this which I have previously requested is the ability to insert a Marker generated from the source, in this case the inserted method skeleton. For example: public void setFoo(int foo){ //$TODO Implement setFoo(int) } Thus, the override methods dialog would result in several new markers telling the user to implement the inserted methods. The user could use the TaskList to navigate to the new methods (please ignore the fact that currently the TaskList is not suited for this task or any other ;-). we are now supporting to sort methods - no further action is planned on this bug There will be no preference setting to invoke sort implicitly when override is invoked?? A new preference is probably undersirable, but what about auto-detecting the fact that the current type is sorted, and invoking sort based on the result of that test? Thanks. What we intend to do is to insert all generated methods according to the order as defined in Preferences>Java>Appearance>Member sort order (obviously this will then no longer be an appearance option only). However, this is unlikely to happen for 2.1 |