Proposal: Concise declaration of JavaBeans properties

[Reinier Zwitserloot]

You're 2.5 months too late with a proposal. Also, I recall similar  
proposals having been suggested during the official proposal period  
(which was the month of march). They did not make the shortlist, for  
some reason.

  --Reinier Zwitserloot



On 2009/25/06, at 12:36, Jan Kroken wrote:

>    PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0
>
>    AUTHOR(S): Jan Kroken
>
>    OVERVIEW
>
>    Add syntactic sugar to reduce the amount of boilerplate code needed
>    to adhere to the JavaBeans specification.
>
>    FEATURE SUMMARY: Should be suitable as a summary in a language  
> tutorial.
>
>    Add a new field modifier, that will generate the neccessary  
> JavaBeans
>    methods at compile time.
>
>    MAJOR ADVANTAGE:
>
>    Significantly reduce the amount of boilerplate code in Java  
> source code.
>
>    MAJOR BENEFIT:
>
>    Reducing the amount of boilerplate code will:
>    - increase readability
>    - reduce the amount of possible programming errors
>    - reduce implementation and maintenance cost
>
>    MAJOR DISADVANTAGE:
>
>    The proposal will increase the complexity of the language.  
> Methods will
>    exist without having an explicit declaration, which may confuse
> programmers
>    not familiar with the feature.
>
>    ALTERNATIVES:
>
>    The same feature can possibly be implemented using annotations and
>    runtime code generation.
>
>    EXAMPLES
>
>    SIMPLE EXAMPLE:
>
>    A value class in the current java language:
>
>    public class MyValueObject {
>      private Type1 field1;
>      private Type2 field2;
>
>      public void setField1(Type1 field1) {
>          this.field1 = field1;
>      }
>
>      public Type1 getField1() {
>          return field1;
>      }
>
>      public Type2 getField2() {
>          return field2;
>      }
>    }
>
>    The same value with the proposed language modification
>
>    public class MyValueObject {
>      private :exposed(rw) Type1 field1;
>      private :exposed(r) Type2 field2;
>    }
>
>    Note that :exposed is not the suggested syntax modification.
>    The exact notation should be decided upon by the working group.
>
>    In the above example, :exposed(rw) will expose the value both
>    through a getter and setter, while :exposed(r) will expose the
>    value only through a getter.
>
>    ADVANCED EXAMPLE:
>
>    Any explicit declarations of a JavaBeans method in the current  
> class
>    will ensure that the method is not generated based on the field
>    declaration.
>
>    For instance, the class
>
>    public class MyValueObject {
>      private :exposed(rw) Type1 field1;
>      private :exposed(r) Type2 field2;
>
>      public void setField1(Type1 field1) {
>          if(field1 == null) {
>              throw new NullPointerException();
>          }
>          this.field1 = field1;
>      }
>    }
>
>    will be equivalent to
>
>    public class MyValueObject {
>      private Type1 field1;
>      private Type2 field2;
>
>      public void setField1(Type1 field1) {
>          if(field1 == null) {
>              throw new NullPointerException();
>          }
>          this.field1 = field1;
>      }
>
>      public Type1 getField1() {
>          return field1;
>      }
>
>      public Type2 getField2() {
>          return field2;
>      }
>    }
>
>    DETAILS
>
>    SPECIFICATION:
>
>    A modifier, currently represented by :exposed(specification),
>    should be added to class fields.
>
>    The modifier has two optional arguments, r (read) and w (write).
>    a read argument specifies that the compiler should generate
>    public JavaBeans read methods for the field. The write argument
>    specifies that the compiler should generate a public JavaBeans
>    set method for the field.
>
>    If the field is a boolean field, both a getField and a isField
>    method will be generated. If one of those are declared in the
>    current class, none will be generated. This is to avoid a loophole
>    where a transformation is added to one of those, while the field
>    is accidentally made available through the other.
>
>    if no arguments are provided, both read and write methods will
>    be generated.
>
>    Any explicit declarations of a JavaBeans method in the current  
> class
>    will ensure that the method is not generated based on the field
>    declaration.
>
>    If a field is declared as an exposed, and there is a conflict with
>    JavaBeans methods implemented in a superclass, the JavaBeans  
> methods
>    will be generated, and override the ones declared in the  
> superclass.
>
>    The added field modifier should be chosen so it does not conflict
>    with any existing Java source code.
>
>    The change would be implemented as desugaring at compile time. The
>    class file format or type system will not be affected.
>
>    The effect this change will have on stack trace information and
>    debugging information has not been analyzed.
>
>
>    TESTING:
>
>    It will be possible to create test code with a full coverage of all
>    variants.
>
>    LIBRARY SUPPORT:
>
>    There is no need for library support.
>
>    REFLECTIVE APIS:
>
>    This change will not require changes to the reflection apis.
>
>    OTHER CHANGES:
>
>    The only component that needs to be modified is the compiler.
>
>    MIGRATION: Sketch how a code base could be converted, manually or
> automatically, to use the new feature.
>
>    A class could be modified through a series of transformations:
>
>    if there is a setter that matches the JavaBeans specification for a
>    field, and the setter does not contain any other operations than
> assigning
>    the field to the passed arguemnt, then the setter can be removed,  
> and
>    the modifier :exposed(w) be added to the field declaration.
>
>    if there is a getter that matches the JavaBeans specification, the
> getter
>    only returns the field value without performing any other  
> operations,
> and
>    there is not another getter not complying with these criteria, the
>    getter(s) can be removed, and the modifier :exposed(r) be added  
> to the
>    field declaration.
>
>    redundant occurences of :exposed(r) or :exposed(w) in one field
>    declaration should be removed.
>
>    If a field declaration has both an :exposed(r) and an :exposed(w)
>    modifier, both should be removed and replaced with a modifier
>    :exposed.
>
>
>    COMPATIBILITY
>
>    BREAKING CHANGES:
>
>    No existing java programs will break. However, parsers, compilers  
> and
>    source analyzing applications for the java language will break,  
> and have
>    to be modified.
>
>    EXISTING PROGRAMS:
>
>    There will be no changes in behaviour for existing programs,  
> neither
>    class files nor programs compiled from source.
>
>    REFERENCES
>
>    EXISTING BUGS:
>
>    URL FOR PROTOTYPE (optional):
>
>    No prototype at this time.
>