[
https://issues.apache.org/jira/browse/GROOVY-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032206#comment-17032206
]
Paul King commented on GROOVY-9369:
-----------------------------------
I've had a look into this and it isn't going to be easy to revert. I'm
reluctant to hold up the 3.0.0 release because of this but we typically have
minor releases (e.g. 3.0.1, 3.0.2, etc.) fixes quite soon after major releases.
We can try to address then if possible.
> 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)
