[jira] [Commented] (GROOVY-9993) CLONE - Field and a property with the same name: clarification of boundary cases

["Paul King (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312950#comment-17312950 ] 

Paul King commented on GROOVY-9993:
-----------------------------------

[~emilles] I fixed up the doco as per current behavior and guidelines for using the existing behavior. There is a breaking change we could do on that issue that would eliminate some current behavior which many might find puzzling.

> 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.3.4#803005)