Bug 13958 - Create Field Wizard/Generate Getter/Setter with tester [code manipulation]
Summary: Create Field Wizard/Generate Getter/Setter with tester [code manipulation]
Status: RESOLVED DUPLICATE of bug 35870
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: test, ui, usability
Depends on: 7154
Blocks:
  Show dependency tree
 
Reported: 2002-04-16 19:43 EDT by Sidney Monteiro Jr CLA
Modified: 2003-04-01 05:39 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sidney Monteiro Jr CLA 2002-04-16 19:43:18 EDT 
The scope (final,static), visibility (public,private), indepedent generation 
choices present in VAJ's 'add field' wizard are not part of the process to add 
getters and setters in eclipse. 

What about providing a dialog with those choices?
And generating the getter an setter automatically generated a tester code for 
JUnit ... 
{ pseudo code ... setX(k); assert(getX() == k) ; setX(j);  assert(getX() == 
j) ... } THEN it would have an advantage over the VAJ wizard ....
Comment 1 DJ Houghton CLA 2002-04-16 20:10:48 EDT 
Moving to JDT/UI for comment.
Comment 2 Sidney Monteiro Jr CLA 2002-04-18 00:54:03 EDT 
The additional testing code is NOT to test the auto generated code...  :)
The testing code is to ensure that modifications done AFTER generation of the 
getters and setters do not violate the obvious gettter/setter contract.

Since the code generation is somewhat simplistic today, if forces a developer 
to visit the implementation of the just generated getter/setter for further 
tweaking; and therefore subjects that to Human error.
Comment 3 Erich Gamma CLA 2002-04-23 06:05:29 EDT 
this would introduce a dependency on an assert facility. We have to support JDK 
1.3 in 2.0. 

deferred
Comment 4 Dirk Baeumer CLA 2002-07-23 12:46:03 EDT 
[code manipulation]
Comment 5 Martin Aeschlimann CLA 2003-04-01 05:39:28 EST 

*** This bug has been marked as a duplicate of 35870 ***