Small property support.

[David Goodenough]

On Wednesday 18 March 2009, Ruslan wrote:
> Hello.
>
> Yes, i have read it.
> But we are trying to fix different things:
> - You are trying to get rid of strings in "Beans Binding of JPA Criteria
> API"
As a matter of interest, how would I pass a property reference using
your proposal?
> - And my point is to make property code readable and get rid of
> getters/setters when use Dependency Injection.
For simple getters and setters, my proposal does actually get rid of 
getters and setters, in that the Property object will do the work for you
using the Field get and set (and some snake oil to handle 
PropertyChangeSupport).

David
>
> HUGE property that was declined by Sun can solve both my and your problem.
>
> So i am trying to solve other issue than you even if we are speaking
> about same things.
>
> BR,
> Ruslan.
>
> David Goodenough:
> > On Wednesday 18 March 2009, Ruslan wrote:
> >> 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.
> >
> > Ruslan,
> >
> > Have you read my Lightweight Property proposal.  It takes a similar
> > approach in that it splits the full Property proposal into smaller
> > chunks, but it does not involve adding a property keyword (any field can
> > be a property) and it does not adding get and set as parts of field
> > declaration.
> >
> > Instead in concentrates on the uses of properties, in places like the
> > Beans Binding frameworks and the JPA Criteria API.  For these it is
> > necessary to have a Property object that can be generated in an IDE
> > or compiler checkable way and can be passed into the framework.
> >
> > David