Small property support.

Ruslan Ruslan.Lazukov at digia.com
Wed Mar 18 05:04:25 PDT 2009


PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

AUTHOR(S): Ruslan Lazukov

OVERVIEW
Create infrastructure for using properties in Java, but make it small change for becoming part of Java 7.
I suggest to use synthetic sugar for properties in Java 7. 

FEATURE SUMMARY: 
Lack of properties in Java make developers to create a lot of solutions for solving this issue.
But issue can be solved only from language level.

MAJOR ADVANTAGE: 
Solve lack of Java property support, but this solve will be small not medium size.

MAJOR BENEFIT: 
Improve check ability of java code. Improve readability of code.
Code become less error prone.

MAJOR DISADVANTAGE: 
Developer should understand how properties work - the same as enhanced for-each.
For-each are synthetic and real code are hidden from developer.

ALTERNATIVES: 
No; Every solution need to change language.

EXAMPLES

SIMPLE EXAMPLE: 
this code made by developer:
    public property int i;
    
    private void foo() {
        this->i = 5;
        int j = this->i;
    }

will be translated by compiler to this code:
    private int i;

    public int getI() {
        return i;
    }

    public void setI(int i) {
        this.i = i;
    }
    
    private void foo() {
        setI(5);
        int j = getI();
    }


ADVANCED EXAMPLE:
code:
   public property String str {
      get {
         return str;
      }
      set {
          this.str = value;
      }
   };

transforms to this code:
   private String str;

   publiv void steStr(String value){
      this.str = value;
   }

   public String getStr() {
      return str;
   }

change this code (from developer side):
obj2.setX(obj.getX() + obj.getY() * (obj.getZ() + obj.getName().length()));

to this code (from developer side):
obj->x = obj->x + obj->y * (obj->z + obj->name.length());


Every developer can easily understand is it a field pr a property.
Field can be accessed by '.' (dot), and property by '->' (arrow).

Examples can be read here http://docs.google.com/Doc?id=dfhbvdfw_1f7mzf2


DETAILS
SPECIFICATION: 
Main problem of Java property support in Java 7 is that Sun want to create solution at one step.
But also Sun do not have enough time and resources to do this for Java 7.

My suggestion is to split "property" into many steps, and make some of them in Java 7.

We can use documentation created for HUGE property support, and write code only in java compiler. 
All other stuff like changes in Reflection API - stay for next 3-5 years (for Java 8 release).

HUGE property support described here http://docs.google.com/Doc?id=dfhbvdfw_1f7mzf2

I suggest implementation of language changes without Property object, changes in Reflection API and necessity to sit 
and wait 5 years for time when Java code become more readable.


COMPILATION: How would the feature be compiled to class files?
No additional support necessary in class files.

TESTING: How can the feature be tested?
The same way as for-each.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?
No, not for Java 7.

REFLECTIVE APIS: 
No, not for Java 7.


OTHER CHANGES: 
No, not for Java 7.

MIGRATION: 
No migration needed.


COMPATIBILITY
BREAKING CHANGES: 
All existing programs remain valid.

EXISTING PROGRAMS: 
The semantics of existing class files and legal source files and are 
unchanged by this feature.

REFERENCES EXISTING BUGS: 
I think that there is a lot of bugs in Sun bug-tracking system.

URL FOR PROTOTYPE (optional):
Document about HUGE property that Sun presented to developers 
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf, page 27.

Also Sun (probably) developers create a lot of documentation how property should be supported from language level.
That documents have to be used to implement this proposal fast and easy.
HUGE property support described here http://docs.google.com/Doc?id=dfhbvdfw_1f7mzf2


WBR, Ruslan.




More information about the coin-dev mailing list