@Immutable should not override toString() if provided in source

Did you mean?

String toString() { 'some return value' }

ImmutableASTTransformation also adds equals() and hashCode() too. Should they also not be added if they are already provided in source.

I understand that from Class Format point of view, they should not be added but does anyone see any conflict it would create with the @Immutable functionality? If there is some issue there, then some other solution may have to be adopted.

Immutability comes partly from the fact equals() and hashCode() work the way they're implemented by the @Immutable transformation.
So someone could break the immutability if he provided a wrong equals() and hashCode() himself – but toString() should be okay if a user provide his own.
Instead, I think we should throw a compilation error if someone provides their own equals() and hashCode().

Paul King may want to add some thoughts there, as @Immutable is his baby

I will try the toString() change in the meanwhile and wait for more comments on whether users can be told up-front that they should not provide hashCode() / equals() with @Immutable. Some change there is needed anyway because if they provide, class generated will run into ClassFormatError due to repetitive hashCode() / equals() methods.

Attaching a patch with

1) throwing errors for overridden equals() / hashCode()

2) allowing users to override toString() by not adding the generated toString() if it is provided.

Roshan, why don't you use cNode.getDeclaredMethods("equals") and such?

Just getting back into work after returning from Agile 2009. I'll take a look at this today. Patch looks good - though I am in two minds about whether to allow equals/hashCode methods to be overridden as well.

Attaching a newer patch that uses getDeclaredMethods() and has a test case.

I ended up allowing equals and hashCode to be overridden as well since we allow additional (non-property) state variables to be added which up until now we could only ignore - now we can allow code for most "properties" to be automatically generated but have an extensible way to handle some properties manually.

superb, thanks
Dierk