Small property support.

[Ruslan]

Hello.

It was a joke :) but every joke have it's serious side. So i will answer 
on serious side.

I will be happy to use your tine property support. But it creates more 
problems than my proposal.
Without "property" keyword - it can be unclear why in one place

@Get @Set
private int i;

create both getter and setter, and in another only one of them. Java is 
very good because it is readable.
This issue appear because in first class imported annotations are: 
java.property.Set and java.property.Get
And in another class java.property.Set and some.other.package.Get


Same thing is with arrow (->) and point (.).

With arrow i can easily understand can some code throw exception 
(because getter/setter can throw exceptions). And with point i can not.
With point you can not access getter and variable at the same place:

private property int i;


public void foo2() {
int j = this.i;
j = getI();
}

public void foo2() {
int j = this.i;
j = this->i;
}

So arrow should be in this proposal.

And at the end: it's much more harder to write getter function with 
using of Java annotations right now. So for you proposal necessary to 
change annotations too.


BR, Ruslan.


PS i would like to have any type of property support faster than in 5 
years. 5 years - time before java 8 will be released... may be ;)


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.