Small property support. (original) (raw)

Ruslan Ruslan.Lazukov at digia.com
Tue Mar 24 07:13:13 PDT 2009

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.

More information about the coin-dev mailing list