| Summary: | Feature Request: Constructor Wizard | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Hugh Ha <hugh> | ||||||||
| Component: | UI | Assignee: | Randy Faust <rfaust> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | martinae, peter_burka | ||||||||
| Version: | 3.0 | ||||||||||
| Target Milestone: | 3.0 M2 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
Is on the M2 plan. Give me some input as to how you'd like to see this work. Take for example:
public class AddConstructorTestA {
public AddConstructorTestA(int collection, String name, Object[]
array) {}
}
public class AddConstructorTestB extends AddConstructorTestA {
private int fNumberofRazors;
private int fNumberOfSpeakers;
private Vector fSomeBigCollection;
private String fObjectName;
private String fBlanketName;
private Object[] fArray;
private InputStream[] fInputArray;
}
You want best guesses on the pairing of the constructor parameters to the
fields that exist? We can make educated guesses if the names are close, but in
a lot of cases we might not get it right. How is the tree in the dialog
supposed to look? Should there be child nodes for each of the constructor
options which contain the field names? What happens when we can't make a guess
for one of them? Should this be editable (might be heavyweight in this case)?
What I imagined really doesn't require any "guessing." Perhaps you're thinking of something a bit more flexible. The wizard dialog would simply display a list of instance variables that you've already declared or is inherited, each with a checkbox. The user can check off which variables he/she would like to be initialized in the constructor. That's it. The constructor created would have a signature that includes all the selected variables as parameters and its body would simply initialize the instance variables to the corresponding passed parameters. I don't think it's a good idea to keep track of what constructors have been created or exists, or create some kind of list of all the possible constructors. This wizard is simply for code generation, nothing more. The dialog should probably separate the inherited instance members from the normal ones. The default selected could be the last ones used. My feeling is that this wizard will only provide a quick start to constructor creation. The code generated won't be sufficient in a lot of cases. If there are ways to make it more flexible, I'm all for it. Alright. I understand better now. What you're imagining is beyond the current scope of the existing creating constructor dialog, but is feasible. Do you imagine being able to create more than a single constructor at a time with this dialog enhancement? I don't see it as absolutely necessary to be able to add multiple constructors at the same time, but it could be discouraging if you really needed to do exactly that and had to re-open the wizard multiple times. A good compromise could be a checkbox that says something like "keep dialog open after I click okay." It would be deselected by default and remember your last preference. The current add constructor from superclass dialog does allow multiple constructor creation. This wizard is outside the scope of that however. Where do you propose the option for it is put? Also under the Source menu? I'm wary of creating two separate source actions for constructor creation. It might cause confusion in when to use each. We got rid of the 'new method' button on the toolbar since VAJ, so I can't imagine putting a button for this create constructor operation on there. Any suggestions? Let's have two actions. We will see if this is too confusing. *** Bug 10733 has been marked as a duplicate of this bug. *** Created attachment 5323 [details]
proposed enhancement.
+ New source action for creating a constructor with fields initialized.
+ Dialog allows reordering of fields (up/down) so that the params passed into
the constructor are is reflected by the order of the fields in the dialog from
top to bottom.
+ Use of "this." before fields is reflected by setting in java->code gen prefs.
+ Static fields can also be set with type name prefixed.
+ Constructor comment is taken constructor template.
+ Makes use of SourceActionDialog to choose insert position and overriding of
comment.
- Setting of public fields from superclass is disallowed.
- Has no action on types with no fields.
released > 20030701 Niiiiiice! Some minor complaints: - 'Create New Constructor...' could be shortened to 'Create Constructor...' - I think your code fails when there are brackets in the constructor comment template - I think we don't need the constructor body template (TODO...). The body is complete as it is. - The new method should be revealed in the editor after the creation Created attachment 5330 [details]
proposed enhancements.
+ up/down moves selected item instead of checked item
+ adds superclass constructor combo
+ changed to "create constructor" from "create new constructor"
+ fields selected now put in parameter list after params for chosen constructor
from superclass
+ new constructor is revealed in editor after creation from structured
selections
Created attachment 5331 [details]
proposed fix.
Same as previous attachment, but with more accurate logic for calculating
position of "(" and "}" in constructor.
patch released > 20030702 |
A constructor wizard that automatically sets instance variables to the passed parameters could save the developer the tedious task of typing all that standard code. The wizard could behave similarly to the generate getter/setter dialog where instance variables could be selected and the basic constructor automatically created. For example, selecting name and title could produce: public Book (String name, String title) { this.name = name; this.title = title; } Although not always the final constructor one would need, it makes for a great starting point, especially when creating multiple constructors for the same class.