Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: The dialog for generating getter/setter method does not have an option for "abstract" More information: It would be helpful to have this option. The template for the code would have a method signature, followed by a ";" and omit the method body.
Move to JDT/UI
Declaring a field and leave the getter/setter implementation to subclasses is a rare use case and in my personal opinion not a very good design. No plans to add this.
Dani's comment is correct for hand-written code. The situation is different for modeled code. Setter methods that include databinding and fire property changes can be tedious to write by hand. Also, if fields in modeled class are annotated with JPA, some object relational mapping methodologies (for example, Hibernate) require the presence of getter/setter methods. It is sufficient that these methods be abstract.
>The situation is different for modeled code. Do you mean generated for a model?
(In reply to comment #4) > >The situation is different for modeled code. > Do you mean generated for a model? > Hi Dani, Yes. The abstract getter/setter is contained in a model. The generated code contains the method body. The method body fires the property changes. The generated class that contains the method defines the (generated) property that is associated with the property change. These combine to provide support for databinding in the (generated) UI classes.
Looks like the previous two comments got lost by the infra server maintenance: --- Comment #5 from CharlieKelly <Eclipse@CharlieKelly.com> 2009-02-15 12:41:40 -0400 --- (In reply to comment #4) > >The situation is different for modeled code. > Do you mean generated for a model? > Hi Dani, Yes. The abstract getter/setter is contained in a model. The generated code contains the method body. The method body fires the property changes. The generated class that contains the method defines the (generated) property that is associated with the property change. These combine to provide support for databinding in the (generated) UI classes.
>The generated class that contains the method defines the (generated) property >that is associated with the property change. Good. If it generates the property and if it really needs the abstract methods then it should also generate those.
(In reply to comment #5) > >The generated class that contains the method defines the (generated) property > >that is associated with the property change. > Good. If it generates the property and if it really needs the abstract methods > then it should also generate those. > Hibernate/JPA requires that they be in the model class (otherwise the model class cannot be included in the persistence hierarchy).
Yes, but don't you generate the model class?
(In reply to comment #7) > Yes, but don't you generate the model class? > No, the model class is written "by hand". It is input to the generator
I see.
