groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (GROOVY-7950) AST transforms referencing properties on a class not detecting Trait-mixed in properties
Date Sat, 01 Oct 2016 06:47:20 GMT

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

Paul King edited comment on GROOVY-7950 at 10/1/16 6:46 AM:
------------------------------------------------------------

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 includes you could still do that {{@TupleConstructor(includeFields=true,
includes='s2, T__s1')}}.


was (Author: paulk):
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)

Mime
View raw message