[jira] [Commented] (GROOVY-7950) AST transforms referencing properties on a class not detecting Trait-mixed in properties
[
https://issues.apache.org/jira/browse/GROOVY-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637440#comment-17637440
]
Eric Milles commented on GROOVY-7950:
-
The getter, setter and field are added by the time {{@TupleConstructor}} is
applied, as noted above. You can include the "pseudo properties" like this:
{code:groovy}
trait T {
String s1
}
@groovy.transform.TupleConstructor(includes='s1,s2', allProperties=true)
class C implements T {
String s2
}
def obj = new C('x','y')
assert obj.s1 == 'x'
assert obj.s2 == 'y'
{code}
> 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
>Affects Versions: 2.4.7
>Reporter: Kamal Advani
>Priority: Major
> Labels: trait, traits
>
> 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
(v8.20.10#820010)
[jira] [Commented] (GROOVY-7950) AST transforms referencing properties on a class not detecting Trait-mixed in properties
[
https://issues.apache.org/jira/browse/GROOVY-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
