Community
Participate
Working Groups
bug report collecting all improvement suggestions for the getter/setter dialog
*** Bug 26592 has been marked as a duplicate of this bug. ***
*** Bug 10858 has been marked as a duplicate of this bug. ***
*** Bug 32483 has been marked as a duplicate of this bug. ***
*** Bug 13958 has been marked as a duplicate of this bug. ***
*** Bug 15840 has been marked as a duplicate of this bug. ***
*** Bug 18757 has been marked as a duplicate of this bug. ***
It would have been much better to say that this bug depends on all of these others, rather than they are duplicates. There is no information in here to what the bug reports actually are; this bug could have been created as a super-bug by depending on the others, and thus seen a dependency tree. Marking them as duplicates indicates they are all the same solution, which they may not be. --> bug 26592 said In the 'Generate getter/setters' method, there are buttons to select all and dselect all. It would be useful to have two other buttons; select read methods and select write methods. That way, it would be easy to create a read-only object that multiple fields but with no set methods. Of course, this can be done manually at the moment by only selecting the getter methods, but having a button to just select the read only methods would be useful.
The plan is to implement all these issues at once.
*** Bug 24681 has been marked as a duplicate of this bug. ***
Created attachment 4712 [details] proposed fixes. Enhancements in patch: - adds "select all getters" and "select all setters" buttons - adds toggle for sorting the methods alphabetically into class - creates set/get pairs instead of all sets/all gets - adds options for final, static, public, private, protected, default, abstract - methods are entered at current cursor position To Do: - better support for entering methods at current cursor position (should jump to next method using GoToNextPreviousMemberAction) - support for entering into file after current element location when selected in Java outline view Also To Explore: - add autogeneration of JUnit tests - lazy creation for complex types in getter (using templates?)
Created attachment 4713 [details] earlier patch file contains extraneous code
Created attachment 4793 [details] proposed enhancements. - adds option for sorting alphabetically - adds option for sorting by set/get pairs - adds visibilities: public, private, protected, default - adds modifiers: final, native, synchronized - adds option to enter new methods at cursor location when applicable - adds option to enter new methods at chosen existing method location - cleans up dialog L&F - fixes consistency of labels/titles in dialog TODO: - use templates for method construction - remove body of methods marked as native
patch released > 20030506
almost all proposals are now implemented in 3.0 M1 - sort order of the create method either by getter/setter pair or getter then setters - insertion point (initialized to cursor position when invoked from the editor's context menu) - select visibility - code template for getter/setter body (on Code Generation preference page) (user can configure it to lazy initialization or add asserts for setters) - select all getters / all setters Please speak up if some request were forgotten (please open a new bug report)
Could you elaborate on the sorting that was implemented. Bug 10858 requested that the added method be sorted among existing methods, not sorted among themselves.
they are sorted among themselves and inserted at a single insert position. No plans to sort in existing methods.
I concur that this fix does not address Bug 32483 or 10858. These bugs should be reopened since they are not part of the fix (and is one of the problems of marking bugs as duplicates when they are not in fact duplicates, but a grouping mechanism). I think that it would be desirable (bug 10858) to re-sort members after adding existing ones, though not mandatory. Perhaps it would be desirable to have an auto-sort checkbox defined in the preferenecs where modifications (specifically addition of members) could automatically re-sort members as defined by the 'Sort Members' option. Whether the sort members would benefit from grouping getter/setters is probably the subject of a new bug, should anyone wish to raise that.
I agree with Alex. I fail to see the point of sorting only the small number of methods that are being added. Also, why would the sorting options here be different that the sorting options for the "Sort Member" action. If someone wants to group getter and setters, then they probably want to do it everywhere. I'm reopening bug 10858. CC if interested.
