Small property support.

[Michael Bien]

I would even start smaller, should I call it tiny property support? ;)

@get @set
private int i;

would tell the compiler to generate getter setter and property change 
listener methods for the field 'i'. No additonal keywords and no 
arrow(->) syntax required.

Writing the property 'i' in the bean would cause a compiler warning, 
reading would be fine. Calling setters would be the preferred way to 
modify properties from inside or outside the bean.

I know Annotations are not intended to change the meaning of a field or 
its behaviour. But this is rather a shortcut to the bean pattern than 
the usual language change proposal.

I see it rather as temporary and probably even as smallest possible 
property feature instead of a final solution. JDK8 could add real first 
class properties without conflicts with this proposal (again its just 
the bean pattern), you could even keep the Annotations it wouldn't hurt.

no changes to javadoc, compiler etc.

what do you think? Should I try to file a proposal or do you already 
spot show stoppers?

best regards,

Michael Bien

Ruslan wrote:
> Hello.
>
> David Goodenough wrote:
>   
>> 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?
>>   
>>     
> My proposal have another goal. Goal is to have synthetic sugar like 
> for-each for property.
> And in my case there is not property reference, so you can not pass it.
>
> Property references can be added at next release (5 years later ;) ).
>
>
>   
>>> - 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).
>>   
>>     
> Yes, that is true. And my proposal are not using Property or Field. It's 
> like macros for property get/set generation.
>   
>> David
>>   
>>     
> PS my goal is to avoid situation like this:
>     private int i;
>    
>     public String getI() {
>         return Integer.toString(i);
>     }
>    
>     public void setI(long i) {
>         this.i = (int)i;
>     }
>
> What is the type of property 'i' ?
>
> private int i;
>    
>     public int getJ() {
>         return i;
>     }
>    
>     public void setI(int i) {
>         this.i = i;
>     }
>
> IS everyone see that there is not getter for 'i' - we have getter for 
> 'j'. But compiler will not fix this error, because it is a logical 
> error, not language.
>
>
> Ruslan.
>
>
>