[
https://issues.apache.org/jira/browse/GROOVY-10713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yih Tsern updated GROOVY-10713:
-------------------------------
Description:
E.g.
{code:java}
class SomeClass {
def someClosureField = {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
def someMethod() {
// Expressions are visited by
ClassCodeExpressionTransformer.transform(Expression)
3.times {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
def someClosureVar = {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
}
}
{code}
Is this current behaviour by design or is it a bug? If it is by design, it
seems to be quite a gotcha (also caused GROOVY-6932 & GROOVY-6434) - probably
should be noted in [the
doc|https://groovy-lang.org/metaprogramming.html#_classcodeexpressiontransformer]?
Below is my current workaround(??) - is this the expected way to work with
ClassCodeExpressionTransformer?
{code:java}
class MyAstTransformer extends ClassCodeExpressionTransformer {
Expression transform(Expression expression) {
// Some code to deal with specific expression classes...
...
if (expression instanceof ClosureExpression) {
expression.code.visit(this)
}
super.transform(expression);
}
}
{code}
was:
E.g.
{code:java}
class SomeClass {
def someClosureField = {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
def someMethod() {
// Expressions are visited by
ClassCodeExpressionTransformer.transform(Expression)
3.times {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
def someClosureVar = {
// Expressions are NOT visited by
ClassCodeExpressionTransformer.transform(Expression)
}
}
}
{code}
Is this current behaviour by design or is it a bug? If it is by design, it
seems to be quite a gotcha (also caused GROOVY-6932 & GROOVY-6434) - probably
should be noted in [the
doc|https://groovy-lang.org/metaprogramming.html#_classcodeexpressiontransformer]?
Below is my current workaround(?) - is this the expected way to work with
ClassCodeExpressionTransformer?
{code:java}
class MyAstTransformer extends ClassCodeExpressionTransformer {
Expression transform(Expression expression) {
// Some code to deal with specific expression classes...
...
if (expression instanceof ClosureExpression) {
expression.code.visit(this)
}
super.transform(expression);
}
}
{code}
> ClassCodeExpressionTransformer ignoring Expressions within
> ClosureExpression.code
> ---------------------------------------------------------------------------------
>
> Key: GROOVY-10713
> URL: https://issues.apache.org/jira/browse/GROOVY-10713
> Project: Groovy
> Issue Type: Bug
> Reporter: Yih Tsern
> Priority: Minor
>
> E.g.
>
> {code:java}
> class SomeClass {
> def someClosureField = {
> // Expressions are NOT visited by
> ClassCodeExpressionTransformer.transform(Expression)
> }
>
> def someMethod() {
> // Expressions are visited by
> ClassCodeExpressionTransformer.transform(Expression)
> 3.times {
> // Expressions are NOT visited by
> ClassCodeExpressionTransformer.transform(Expression)
> }
> def someClosureVar = {
> // Expressions are NOT visited by
> ClassCodeExpressionTransformer.transform(Expression)
> }
> }
> }
> {code}
> Is this current behaviour by design or is it a bug? If it is by design, it
> seems to be quite a gotcha (also caused GROOVY-6932 & GROOVY-6434) - probably
> should be noted in [the
> doc|https://groovy-lang.org/metaprogramming.html#_classcodeexpressiontransformer]?
>
> Below is my current workaround(??) - is this the expected way to work with
> ClassCodeExpressionTransformer?
>
> {code:java}
> class MyAstTransformer extends ClassCodeExpressionTransformer {
> Expression transform(Expression expression) {
> // Some code to deal with specific expression classes...
> ...
>
> if (expression instanceof ClosureExpression) {
> expression.code.visit(this)
> }
> super.transform(expression);
> }
> }
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
