[jira] [Comment Edited] (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=17311847#comment-17311847 ] 

Paul King edited comment on GROOVY-9993 at 3/30/21, 11:05 PM:
--------------------------------------------------------------

[~emilles] So far the doco clarifications haven't touched upon inheritance. GROOVY-8659 is certainly something which needs further work. It probably belongs as a separate PR - it may even require breaking code changes for some edge cases. We should at least check that the direction we want to head for that is compatible with the changes for this issue.


was (Author: paulk):
So far the doco clarifications haven't touched upon inheritance. It is certainly something which needs further work. It probably belongs as a separate PR - it may even require breaking code changes for some edge cases. We should at least check that the direction we want to head for that is compatible with the changes for this issue.

> 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
>
>
> 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)