[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032220#comment-17032220
]
Jochen Theodorou commented on GROOVY-9369:
------------------------------------------
[~paulk] this sounds like the MOP broke. If yes, then this is a major break
and, if not intended, should delay 3.0. But I am actually surprised that our
tests did not catch this. Or maybe it is not as dramatic as it sounds from this
issue... Afaik the old logic is, if getProperty is overwritten, we call
getProperty, otherwise we call the getter directly...
> Unable to distinguish foo.x and foo.getProperty("x") in call interceptor
> ------------------------------------------------------------------------
>
> Key: GROOVY-9369
> URL: https://issues.apache.org/jira/browse/GROOVY-9369
> Project: Groovy
> Issue Type: Task
> Components: groovy-runtime
> Affects Versions: 3.0.0-rc-2, 3.0.0-rc-3
> Reporter: Marcin Zajaczkowski
> Priority: Major
>
> TL;TR. It is problematic in Groovy 3 to distinguish go.x and
> go.getProperty("x") in a call (at the level of an interceptor for a mocking
> system)?
> A ticket to track problem raised using the [mailing
> list|https://mail-archives.apache.org/mod_mbox/groovy-dev/202001.mbox/%[email protected]%3e]
> . Quoted original concerns:
> {quote}Working on the Spock adjustment to Groovy 3 I spotted that Groovy 3
> started for a property access go.x (go - some GroovyObject instance with
> a field "x") to call go.getProperty("x") instead of go.getX() directly
> (as it took place in Groovy 2). This broke tests for mocking with a
> property call (getX() is stubbed, but go.x is called) and forced me to
> detect getProperty("x") calls in a mock interceptor - to analyze deeper
> and check which method (here getter) is being called and if has been
> stubbed.
> However, in addition, it should be possible to just stub direct
> go.getProperty("x") calls [1]. To do that, currently, I have to analyze
> a stack trace to detect groovy.lang.GroovyObject$getProperty.call() at
> the position -3 [2] (for direct go.getProperty("x") calls) and deeper
> process only the other calls (go.x). It seems to work, but it's quite
> ugly and fragile. I wonder, how to reliably differentiate those two
> types of calls?
> [1] -[
> https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81|https://github.com/spockframework/spock/blob/1dd24a2251afe3151e04b50af8afb6285b236c76/spock-specs/src/test/groovy/org/spockframework/smoke/mock/JavaMocksForGroovyClasses.groovy#L75-L81]
> [2] -[
> https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76|https://github.com/spockframework/spock/commit/1dd24a2251afe3151e04b50af8afb6285b236c76]
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
