the field doesn't need to be final IMHO (dk) My view is that the field should be final(tug)
public x
protected x
private x
public final x
a public final field like in Java
@Property x
if it's still supported (MrG) My proposal is to remove it (tug)
other permutations?
what happens with static? (MrG) Static behave exactly the same(tug)
Migration notes
Basically if you have @Property at the moment then you will need to remove it. If the declaration is typed then you are done. If it's not then you need to replace the @Property with def.
If you have field declarations which have default visibility (def x or String y, for example) then these will become properties. If you are using them from Groovy then you won't *have* to do anything. If they are accesses from Java then you will need to make them fields again. If you want them to still be fields you need to put public in front of the declaration.
Fields which are declared public, protected or private can be left alone.
If you would like to prepare for this then you can start to declare visibility for all your fields. The when we remove @property you can run a sed script which removes all the changes @Property to def and then compile your source. The compiler will than complain about the use of def and a type and you will need to remove all these defs.
I am not sure whether or not this is the right place for this comment, but when it comes to properties, one of the most common use cases are properties that are "read only" outside of the class. That is to say those that have a getter and not a setter. You might call those "immutable" as for the client of the class they are immutable, but for the class itself they are not.
Groovy makes common use cases easy. So why not add a keyword (or an annotation) that accommodates this use case? You could add to the private, protected, public trio another visibility level: "immutable", as in:
Class Example { immutable myprop = "x" }
Which will create a propery that is read-only outside of the class. And so:
Example ex = new Example(); assert ex.myprop == 'x'
But:
ex.myprop = 'y'
would throw an exception...
Site running on a free Atlassian Confluence Open Source Project License granted to The Codehaus. Evaluate Confluence today.
Also note that a statically typed field declaration does not change the proposed table. For example:
As tug says, there is no magic in "def".
I am not sure whether or not this is the right place for this comment, but when it comes to properties, one of the most common use cases are properties that are "read only" outside of the class. That is to say those that have a getter and not a setter. You might call those "immutable" as for the client of the class they are immutable, but for the class itself they are not.
Groovy makes common use cases easy. So why not add a keyword (or an annotation) that accommodates this use case? You could add to the private, protected, public trio another visibility level: "immutable", as in:
Which will create a propery that is read-only outside of the class. And so:
But:
would throw an exception...