[jira] [Commented] (GROOVY-7950) AST transforms referencing properties on a class not detecting Trait-mixed in properties

["Paul King (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15538031#comment-15538031 ] 

Paul King commented on GROOVY-7950:
-----------------------------------

This is probably what you have missed or under-estimated the significance of:

http://docs.groovy-lang.org/next/html/documentation/core-traits.html#_compatibility_with_ast_transformations

TLDR: traits aren't guaranteed to work with (other) AST transforms.

So even though the trait "transform" (kind of an implementation detail that it is implemented that way) has run during SEMANTIC_ANALYSIS and has added a trait "pseudo" property s1, it has a hard-coded implementation and isn't deemed the same as a normal property. It isn't in the list of properties that the {{TupleConstructor}} transform looks for (even though it does run later in the compilation process). If you use "Inspect AST" in the Groovy console you will see a {{T__s1}} backing field and hard-coded accessors after the semantic analysis phase has run.

We would in the long-run like traits and transforms to be fully aware of each other and compatible but the deeper we make the compatibility the closer we tie current transforms to the current trait implementation details. So we have deliberately not tried yet to have deep compatibility since traits are still a relatively new feature in the language. I guess some time has passed and we might consider soon doing some further integration between the two.

Having said that, while we don't currently support deep integration between the two features, we don't deliberately cripple functionality. If you know what each feature is doing you can often workaround the current limitations with the understanding that you might need different workarounds at some later point. So proceed with caution!

The workaround for you right now might be:
{code}
@TupleConstructor(includeFields=true)
class Bar implements T {
    String s2
}

def bar = new Bar('foo', 'baz') // currently properties come before fields
assert bar.s2 == 'foo'
assert bar.s1 == 'baz'
{code}
If you really needed fine-grained included you could still do that {{@TupleConstructor(includeFields=true, includes='s2, T__s1')}}.

> AST transforms referencing properties on a class not detecting Trait-mixed in properties
> ----------------------------------------------------------------------------------------
>
>                 Key: GROOVY-7950
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7950
>             Project: Groovy
>          Issue Type: Bug
>          Components: ast builder
>    Affects Versions: 2.4.7
>            Reporter: Kamal Advani
>
> I can't find anything about this in http://docs.groovy-lang.org/next/html/documentation/core-traits.html -- apologies if I missed it elsewhere. Also could not find a similar issue.
> I am applying a transform that references properties in a class, the transformed class also implements a trait with properties. It seems that the trait transform is applied last, such that the annotation-driven AST transforms don't see 'inherited/mixed in' trait properties.
> {code}
> import groovy.transform.*
> trait T {
>     String s1
> }
> @TupleConstructor(includes='s1, s2') // only a constructor for s2 created, same applies to @EqualsAndHashCode for example.
> // @Sortable(includes='s1, s2') //  Error during @Sortable processing: tried to include unknown property 's1'
> class Bar implements T {
>     String s2
> }
> {code}
> This http://docs.groovy-lang.org/next/html/documentation/core-traits.html#_compatibility_with_ast_transformations talks about applying transforms on a trait itself, but as per above, this isn't what I'm doing.
> Is this behaviour by design, or am I missing something obvious? 
> Thanks for your help.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)