[
https://issues.apache.org/jira/browse/GROOVY-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-9993:
--------------------------------
Language: groovy
> CLONE - Field and a property with the same name: clarification of boundary
> cases
> --------------------------------------------------------------------------------
>
> Key: GROOVY-9993
> URL: https://issues.apache.org/jira/browse/GROOVY-9993
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Labels: breaking
> Fix For: 4.0.0-alpha-3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A field and property with the same name cause the field to become the backing
> field for the property. This provides a way to override how the default
> private field that would normally be created, however there are a number of
> anomalies:
> # the initial value, if supplied as part of the property is ignored:
> {code}
> class X {
> protected x
> def x = 3
> }
> new X().x // => current: null, expected: 3
> {code}
> # The {{@PackageScope}} AST transform on the backing field used in
> conjunction with a property doesn't yield a property at all.
> {code}
> class X {
> @PackageScope x
> def x
> }
> // current: The property 'x' is declared multiple times
> // expected: a property is created with a package scope backing field
> {code}
> # the semantics for copying of annotations onto the field and getters/setters
> is unclear
> {code}
> // the idea will be to leave the current semantics for the normal property
> case but document it more accurately
> // but have a cleaner semantics for the split definition with explicit
> backing case
> {code}
> # the type of the field is currently used as the type for the getter return
> type and setter param type, ignoring the type, if given, for the property
> {code}
> // the idea will be to instead fail compilation if the types don't match
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
