Convention for read only properties.

Is @Readonly the right name? To me that seems close to what final would give you? I suggested @Getter but perhaps there is something better than both.

@Getter implies that the annotated thing is a getter. @GetterOnly is probably more correct, but that describes the implementation rather than the intent, though in this case that is a fuzzy distinction.

Final implies that the value doesn't change, which is subtely different to not being able to set the value from outside. I don't think that there is an English word that clearly expresses that distinction.

Maybe @NoSetter?

I don't mind @NoSetter. There is also the question of whether it belongs within Groovy or something which could be in an optional external library. The other thing to think about is whether this convention is just one of several that might be desirable. Perhaps a more generic option might be something like @Property or @PropertyConfig(setter=false) which could cater for other scenarios too.

Let's not forget the following solution

class Person {
    private String name
    String getName() { name }
}

Perhaps we don't need an AST transformation for everything.

Of course that is a solution, but it is entirely boilerplate. The issue is not that there is no solution for this, but that the current solution is not idiomatic.

This is assuming that Groovy enforces visibility at some stage. In the meantime it would be primarily documentation.

I think the Guill solution works only when the caller is a Java program, because in Groovy there isn't the enforcement of the private modifier, right ?

I like the idea of a @Property AST transformation. For who know Objective-C, it has the @property keyword with some very cool parameters like readonly, atomicity, copy...

Ex:

   class Foo {
     @Property(readonly=true) Bar bar
     @Property(clone=true) Baz baz
     @Property(atomic=true) Zoo zoo
   }

Where:
readonly: only getter
clone: the object will be cloned in the setter
atomic: synchronization between the acessors

What u guys think ?

Some great ideas but I'd want to give a final design some more thought.

One of the things I would also like to be configurable if we head down this path is the ability to have more control over where annotations are placed, i.e. on the field vs the setter vs the getter.

For this particular case, I think the field makes sense as it's the thing that is always there.

I think @Property is the best idea floated.

I wasn't intending to pick one of those options upfront but instead examine whether we could provide a possible additional configuration setting or two, e.g.:

@Override
@Property(annotateField=false) Foo foo

might place @Override on the setFoo and getFoo methods for example.

After the AST transformation suggestion I got in http://jira.codehaus.org/browse/GROOVY-4519, I was kind of thinking about this:

=====
public enum Access {
	PUBLIC,
        PROTECTED,
        PACKAGE, // needed because there's no explicit package scope (it's the absence of access)
        PRIVATE,
        NONE // needed so that you can omit getter or setter
}
=====
@Target(ElementType.FIELD)
@Retention(RetentionPolicy.SOURCE)
public @interface Property {
	Access set() default Access.PUBLIC;
	Access get() default Access.PUBLIC;
	Access field() default Access.PRIVATE; // Access.NONE is a semantic error here
}

Not extremely terse, but normalized. I also pose the question, as I did in GROOVY-4519, if it should be a semantic error for @Property's field() to have equal or more public access than set() or get().

Can someone relate this issue GROOVY-4519? I don't think I have the rights to do so.

A few comments...

1) Doesn't the final keyword on a property remove the setter? I thought a read only property is just one marked final.

2) Concerning the clone and atomic parameters... these options belong in the @AutoClone and @Atomic annotations, not in an @Property annotation. Otherwise, you end up with one giant @Property annotation that needs to change every time a new feature is found. By moving them to different annotations you adhere more to the open-closed principle: the system is open to extension but the individual annotations are closed to modification.

IMO, I would not fix this JIRA. Sorry Luke.