[
https://issues.apache.org/jira/browse/GROOVY-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206294#comment-17206294
]
Eric Milles commented on GROOVY-9768:
-------------------------------------
Map-based types are a bit of a special case. {{MetaClassImpl#getProperty}}
(and other methods in there) assume that all map-based types accept {{String}}
keys and use the {{get}} method to resolve all properties. I tried replacing
{{return ((Map) object).get(name);}} with a check of the return value of
{{get}} as well as {{containsKey}} (for {{withDefault}} behavior). There were
37 test failures in groovy-core. So I think that kind of a change would be a
bit more surprising.
As was stated in previous tickets, there are workarounds for this behavior
change that are cross-compatible with previous Groovy versions:
# use an OWNER_FIRST strategy in this specific case
# add a qualifier to any variable expression that should not come from the map
# enhance the map instance using
{{DegaultGroovyMethods#withDefault(Map,Closure)}} and a closure that throws
{{MissingPropertyExcepton}}
Also, the static member searching for GROOVY-9501, at al. that is found in
{{AsmClassGenerator#visitPropertyExpression}} may actually be better located in
{{VariableScopeVisitor}}. I think a change along these lines would fix the
specific case raised in the example code and similar cases for Spock
(GROOVY-9655, GROOVY-9665).
> Changed behavior of delegates in 4.0.0
> --------------------------------------
>
> Key: GROOVY-9768
> URL: https://issues.apache.org/jira/browse/GROOVY-9768
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.5.13
> Reporter: Grzegorz Kaczmarczyk
> Assignee: Eric Milles
> Priority: Major
> Fix For: 2.5.14, 3.0.6
>
>
> I've noticed difference in how maps behave when used as delegates between
> 2.5.12 (and earlier versions) and 2.5.13. Consider this code snippet:
> {code:java}
> class MapAsDelegateProblem {
> static void main(String[] args) {
> new MapAsDelegateProblem().problematicCode()
> }
> def problematicCode() {
> def map = [:]
> callForAProblem(map) {
> assert "abc" == BAR
> }
> }
> def <U> void callForAProblem(U target, Closure<?> closure) {
> closure.setDelegate(target)
> closure.setResolveStrategy(Closure.DELEGATE_FIRST)
> closure.call(target)
> }
> private static final BAR = "abc"
> } {code}
> In 2.5.x (up to 2.5.12) this code works just fine. Static field {{BAR}} is
> accessed from closure in line 10. But this breaks in 2.5.13. This affects
> also tests written in Spock. Utility method
> {{spock.lang.Specification::with}} works in the same way as
> {{callForAProblem}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
