[
https://issues.apache.org/jira/browse/GROOVY-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Murphy Heiberg updated GROOVY-12598:
------------------------------------------
Description:
{code:groovy}
trait T {
def cnt = 1
def m() { [cnt: 42].with { cnt } }
}
class C implements T {}
assert new C().m() == 42
{code}
Actual: 1. The closure reads the trait's own property, in dynamic, @TypeChecked
and @CompileStatic code. Assigning, as in a with closure that does cnt = 5,
writes the trait property instead of the map. An accessor-only property (a
getCnt method) behaves the same way, and assigning to it throws
ReadOnlyPropertyException. A method parameter annotated with DelegatesTo and
DELEGATE_FIRST behaves the same as with.
Expected: 42, as for the same code in a class. The delegate is checked first
under DELEGATE_FIRST, and the property of the implementing instance is used
only when the delegate does not have one.
Cause: TraitReceiverTransformer rewrites a reference to a trait field or
property into a direct access on the implementing instance or a field-helper
call, even inside a closure. The closure's resolve strategy is therefore never
consulted.
Seen in 4.0.33, 5.0.8 and 6.0.0.
PR: https://github.com/apache/groovy/pull/3125
was:
{code:groovy}
trait T {
def cnt = 1
def m() { [cnt: 42].with { cnt } }
}
class C implements T {}
assert new C().m() == 42
{code}
Actual: 1. The closure reads the trait's own property, in dynamic, @TypeChecked
and @CompileStatic code. Assigning, as in a with closure that does cnt = 5,
writes the trait property instead of the map. An accessor-only property (a
getCnt method) behaves the same way, and assigning to it throws
ReadOnlyPropertyException. A method parameter annotated with DelegatesTo and
DELEGATE_FIRST behaves the same as with.
Expected: 42, as for the same code in a class. The delegate is checked first
under DELEGATE_FIRST, and the property of the implementing instance is used
only when the delegate does not have one.
Cause: TraitReceiverTransformer rewrites a reference to a trait field or
property into a direct access on the implementing instance or a field-helper
call, even inside a closure. The closure's resolve strategy is therefore never
consulted.
Seen in 4.0.33, 5.0.8 and 6.0.0.
> A trait property referenced from a closure ignores the closure's delegate and
> resolve strategy
> ----------------------------------------------------------------------------------------------
>
> Key: GROOVY-12598
> URL: https://issues.apache.org/jira/browse/GROOVY-12598
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> trait T {
> def cnt = 1
> def m() { [cnt: 42].with { cnt } }
> }
> class C implements T {}
> assert new C().m() == 42
> {code}
> Actual: 1. The closure reads the trait's own property, in dynamic,
> @TypeChecked and @CompileStatic code. Assigning, as in a with closure that
> does cnt = 5, writes the trait property instead of the map. An accessor-only
> property (a getCnt method) behaves the same way, and assigning to it throws
> ReadOnlyPropertyException. A method parameter annotated with DelegatesTo and
> DELEGATE_FIRST behaves the same as with.
> Expected: 42, as for the same code in a class. The delegate is checked first
> under DELEGATE_FIRST, and the property of the implementing instance is used
> only when the delegate does not have one.
> Cause: TraitReceiverTransformer rewrites a reference to a trait field or
> property into a direct access on the implementing instance or a field-helper
> call, even inside a closure. The closure's resolve strategy is therefore
> never consulted.
> Seen in 4.0.33, 5.0.8 and 6.0.0.
> PR: https://github.com/apache/groovy/pull/3125
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
