Comment 1 Dani Megert 2013-04-11 07:51:17 EDT

Can you give a concrete example and explain why this would be useful?

Comment 2 Wolfgang Mattuttis 2013-04-11 08:16:24 EDT

I have an interface:

public interace MyInterface {
    Long getId();

    Long getFirstName();

    Long getLastName();

    Date getBirthDay();

    ...
}

When I create a new class implementing this interface I initially get:

public MyClass implements MyInterface {

    public Long getId() {
        return null;
    }

    ...
}

I would like to see a feature which can generate the field based on the getters (or setters) and have the method bodies implemented with returning the field instead of null.

Example (after running new feature):

public MyClass implements MyInterface {

    private Long id;       // GENERATED

    .
    .                      // OTHER PROPERTIES GENERATED AS WELL
    .

    public Long getId() {
        return id;         // GENERATED
    }

    .
    .                      // OTHER METHOD BODIES GENERATED AS WELL
    .
}


Again could safe a lot of coding in certain circumstances (e.g. in the context of domain, DTO or ORM objects).

Hope this helps

Comment 3 Dani Megert 2013-04-11 08:54:15 EDT

(In reply to comment #2)

I see.

>     public Long getId() {
>         return id;         // GENERATED


We could even be smarter when modifying the existing getter:

getX() {
  some code
  return something;
}
==>
getX() {
  if (fieldX == null) {
    some code
    fieldX= something;
  }
  return fieldX;
}

Comment 4 Wolfgang Mattuttis 2013-04-11 09:05:31 EDT

Yup, this could be some optional 'templating' code.

Comment 5 jules 2014-02-01 14:33:46 EST

*** Bug 427180 has been marked as a duplicate of this bug. ***

Comment 6 jules 2014-02-01 14:37:37 EST

See also description in the bug listed above.  There are at least two cases where this would be useful:

* Implementing an interface/abstract class through the wizard with the option to create stubs for abstract methods enabled
* Performing a "quick fix" of an abstract method unimplemented error

As to whether two steps should be required or there is an option as to whether or not to create the fields in the original dialog/list of fixes/preferences, I'm not sure which is best, but it certainly seems it should be possible to do this.

Comment 7 jules 2014-02-01 14:38:24 EST

Also note -- should also apply to setter methods, not just getters.