Bug 42581 - Better support for code in setter methods
Summary: Better support for code in setter methods
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows 2000
: P5 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-05 03:21 EDT by Tonny Madsen CLA
Modified: 2007-06-22 10:01 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tonny Madsen CLA 2003-09-05 03:21:01 EDT
With 3.0 arrived the ability to specify the code that should be generated for 
setter methods.

Unfortunately this is not really suited for generation of setter methods for 
properties.

Either better support for setter methods or new support for properties is 
wished for.

E.g. I usually have the following code for my primitive properties. Properties 
with non-primitive types have a more complex setter, of cause.

/* ========================================== */
/* <type>: <PropertyName> */

/**
 * The current <comment> 
 */
private <type> my<PropertyName> = <init>;

/**
 * Programmatic name of <code><PropertyName></code> property.
 * 
 * <p>{@link java.beans.PropertyChangeEvent} signaled when property is changed.
 *
 * @see #set<PropertyName>(<type>)
 */
final public static String <PROPERTY_NAME>_PROPERTY = "<PropertyName>";

/** 
 * Returns the current <comment>
 *
 * @return the <comment>
 */
public <type> get<PropertyName>() {
    return my<PropertyName>;
}

/**
 * Set the <comment>
 *
 * @param new<PropertyName> new <comment>
 */
public void set<PropertyName>(<type> new<PropertyName>) {
    <type> old<PropertyName> = my<PropertyName>;
    if (old<PropertyName> == new<PropertyName>)
        return;
    my<PropertyName> = new<PropertyName>;

    firePropertyChange(ORIENTATION_PROPERTY, old<PropertyName>, 
new<PropertyName>);
}
Comment 1 Dani Megert CLA 2004-07-27 05:02:43 EDT
Can you explain what exactly you have in mind here: "better support for setter
methods", e.g. which additions would solve your problem?
Comment 2 Tonny Madsen CLA 2004-08-12 08:02:17 EDT
[Sorry about the late answer... Vacation time...]

Basically I would like eclipse to generate managed properties if wanted -- 
i.e. properties that will issue proper property change events when the value 
is changed.

So:

- "Add getter/setter" should allow me to tick a checkbox "Add managed 
properties" (or similar).

- If this checkbox is not ticked the added code looks as today.

- If this checkbox is ticked the added code should look like the 
set<prpertyName> from the original request:

/**
 * Set the <comment>
 *
 * @param new<PropertyName> new <comment>
 */
public void set<PropertyName>(<type> new<PropertyName>) {
    <type> old<PropertyName> = my<PropertyName>;
    if (old<PropertyName> == new<PropertyName>)
        return;
    my<PropertyName> = new<PropertyName>;

    firePropertyChange(ORIENTATION_PROPERTY, old<PropertyName>, 
new<PropertyName>);
}

- If the <type> is not a primitive type (like boolean and int), the condition 
should be changed to

    if (new<PropertyName> == null ? (old<PropertyName> == new<PropertyName>) : 
new<PropertyName>.equals(old<PropertyName>))
        return;

- If the implementation class (or any base class) does not implement the 
needed firePropertyChange(...) method, the needed support methods should be 
added as well (possibly after a confirmation dialog).

- The two versions of the setter method templates for primitive type and 
Object types can be handled via two different templates.

Does this answer you question?
Comment 3 Dani Megert CLA 2004-08-19 11:03:24 EDT
Yes.

Comment 4 Dani Megert CLA 2004-08-19 11:05:01 EDT
Marking as LATER since this is currently not planned for 3.1.
Comment 5 Dani Megert CLA 2007-06-22 09:59:16 EDT
Get rid of deprecated state.