[ https://issues.apache.org/jira/browse/GROOVY-11367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Milles updated GROOVY-11367: --------------------------------- Description: The rules for property read and write for map-based types has several inconsistencies: {code:groovy} class M extends HashMap<String,Object> { public pub protected pro @PackageScope pack private priv def getAny() {} void setAny(value) {} } {code} 1) read and write do not share a consistent resolution order – noted in 8555 {code:groovy} void test1(M map) { map.pub // obj field (fixed in 5001) map.pro // map property map.pack // map property map.priv // map property map.any // getter (all visibilities -- fixed in 5001) map.empty // map property ("class" and "metaClass" as well) map.pub = null // obj field map.pro = null // obj field map.pack = null // map property map.priv = null // map property map.any = null // setter (all visibilities) map.empty = null // map property ("class" as well) map.metaClass = null // setter } {code} Should access method selection take visibility into account? 2) "this" and "super" have different behavior {code:groovy} // add this to the body of M void test2(M that) { this.pub // field this.pro // field this.pack // field this.priv // field this.any // getter (all visibilities -- fixed in 5001) that.* // see test1 that = this that.* // see test1 } {code} 3) Dynamic and static compilation have different behavior {code:groovy} @groovy.transform.CompileStatic void test3(M map) { map.pub // field map.pro // field map.pack // field map.priv // map property map.any // getter (non-private) or map property (private) map.class // getter map.empty // isser } {code} 4) Closure intercepts some properties {code:groovy} TODO {code} GROOVY-11223, GROOVY-11319, GROOVY-9127, GROOVY-8555, GROOVY-8065, GROOVY-6277, GROOVY-6144, GROOVY-5985, GROOVY-5491, GROOVY-5001, GROOVY-662 was: The rules for property read and write for map-based types has several inconsistencies: {code:groovy} class M extends HashMap<String,Object> { public pub protected pro @PackageScope pack private priv def getAny() {} void setAny(value) {} } {code} 1) read and write do not share a consistent resolution order – noted in 8555 {code:groovy} void test1(M map) { map.pub // obj field (fixed in 5001) map.pro // map property map.pack // map property map.priv // map property map.any // getter (all visibilities -- fixed in 5001) map.empty // map property ("class" and "metaClass" as well) map.pub = null // obj field map.pro = null // obj field map.pack = null // map property map.priv = null // map property map.any = null // setter (all visibilities) map.empty = null // map property ("class" as well) map.metaClass = null // setter } {code} Should access method selection take visibility into account? 2) "this" and "super" have different behavior {code:groovy} // add this to the body of M void test2(M that) { this.pub // field this.pro // field this.pack // field this.priv // field this.any // getter (all visibilities -- fixed in 5001) that.* // see test1 that = this that.* // see test1 } {code} 3) Dynamic and static compilation have different behavior {code:groovy} TODO {code} 4) Closure intercepts some properties {code:groovy} TODO {code} GROOVY-11223, GROOVY-11319, GROOVY-9127, GROOVY-8555, GROOVY-8065, GROOVY-6277, GROOVY-6144, GROOVY-5985, GROOVY-5491, GROOVY-5001, GROOVY-662 > map-based types property semantics > ---------------------------------- > > Key: GROOVY-11367 > URL: https://issues.apache.org/jira/browse/GROOVY-11367 > Project: Groovy > Issue Type: Bug > Reporter: Eric Milles > Assignee: Eric Milles > Priority: Major > > The rules for property read and write for map-based types has several > inconsistencies: > {code:groovy} > class M extends HashMap<String,Object> { > public pub > protected pro > @PackageScope pack > private priv > def getAny() {} > void setAny(value) {} > } > {code} > 1) read and write do not share a consistent resolution order – noted in 8555 > {code:groovy} > void test1(M map) { > map.pub // obj field (fixed in 5001) > map.pro // map property > map.pack // map property > map.priv // map property > map.any // getter (all visibilities -- fixed in 5001) > map.empty // map property ("class" and "metaClass" as well) > map.pub = null // obj field > map.pro = null // obj field > map.pack = null // map property > map.priv = null // map property > map.any = null // setter (all visibilities) > map.empty = null // map property ("class" as well) > map.metaClass = null // setter > } > {code} > Should access method selection take visibility into account? > 2) "this" and "super" have different behavior > {code:groovy} > // add this to the body of M > void test2(M that) { > this.pub // field > this.pro // field > this.pack // field > this.priv // field > this.any // getter (all visibilities -- fixed in 5001) > that.* // see test1 > that = this > that.* // see test1 > } > {code} > 3) Dynamic and static compilation have different behavior > {code:groovy} > @groovy.transform.CompileStatic > void test3(M map) { > map.pub // field > map.pro // field > map.pack // field > map.priv // map property > map.any // getter (non-private) or map property (private) > map.class // getter > map.empty // isser > } > {code} > 4) Closure intercepts some properties > {code:groovy} > TODO > {code} > GROOVY-11223, GROOVY-11319, GROOVY-9127, GROOVY-8555, GROOVY-8065, > GROOVY-6277, GROOVY-6144, GROOVY-5985, GROOVY-5491, GROOVY-5001, GROOVY-662 -- This message was sent by Atlassian Jira (v8.20.10#820010)