Small property support.

[Ruslan]

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"
- And my point is to make property code readable and get rid of 
getters/setters when use Dependency Injection.

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
>