[
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 still have several
inconsistencies:
{code:groovy}
class M extends HashMap<String,Object> {
public pub
protected pro
@PackageScope pack
private priv
def getAny() {}
void setAny(value) {}
}
{code}
# 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?
# "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}
# 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}
# Closure intercepts some properties
{code:groovy}
void test4(M map) {
map.with {
pub // field
pro // map property
pack // map property
priv // map property
directive // closure property
metaClass // closure property (and so on for "owner", "delegate",
"thisObject", ...)
}
}
{code}
# The rules change a bit for fields declared on this and fields declared on
super:
{code:groovy}
class C extends M {
def prop
void test5() {
// 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 still have 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}
void test4(M map) {
map.with {
pub // field
pro // map property
pack // map property
priv // map property
directive // closure property
metaClass // closure property (and so on for "owner", "delegate",
"thisObject", ...)
}
}
class C extends M {
void test4a() {
{ ->
pub // field
directive // closure property
metaClass // closure property
}()
}
}
{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 still have several
> inconsistencies:
> {code:groovy}
> class M extends HashMap<String,Object> {
> public pub
> protected pro
> @PackageScope pack
> private priv
> def getAny() {}
> void setAny(value) {}
> }
> {code}
> # 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?
> # "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}
> # 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}
> # Closure intercepts some properties
> {code:groovy}
> void test4(M map) {
> map.with {
> pub // field
> pro // map property
> pack // map property
> priv // map property
> directive // closure property
> metaClass // closure property (and so on for "owner", "delegate",
> "thisObject", ...)
> }
> }
> {code}
> # The rules change a bit for fields declared on this and fields declared on
> super:
> {code:groovy}
> class C extends M {
> def prop
> void test5() {
> // 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)
