[jira] [Commented] (GROOVY-8455) @TupleConstructor gives wrong ordering when includeSuperFields is set

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on GROOVY-8455:
----------------------------------------

GitHub user paulk-asert opened a pull request:

    https://github.com/apache/groovy/pull/655

    GROOVY-8455: @TupleConstructor gives wrong ordering when includeSuper…

    …Fields is set

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/paulk-asert/groovy groovy8455

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/groovy/pull/655.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #655
    
----
commit bdaea09057cc2428df67441df4770c0b196c6f0d
Author: paulk <pa...@...>
Date:   2018-01-22T13:28:56Z

    GROOVY-8455: @TupleConstructor gives wrong ordering when includeSuperFields is set

----


> @TupleConstructor gives wrong ordering when includeSuperFields is set
> ---------------------------------------------------------------------
>
>                 Key: GROOVY-8455
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8455
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Paul King
>            Priority: Major
>
> When the {{includeSuperProperties}} flag is set, @TupleConstructor includes those properties and historically has done it with properties from parent classes first. This is also true if just the {{includeSuperFields}} flag is set. When both flags are set the intention was to keep this ordering but currently that is not the case.
> Here is an example:
> {code}
> import groovy.transform.*
> class Foopubf{}
> class Foop{}
> class Foopp{}
> class Foo {
>   Foop foop1
>   public Foopubf foopubf
>   protected Short fooProtField = 42
>   void setFooPseudoProp(Foopp fpp) {}
>   Foopp getFooPseudoProp() { null }
> }
> class Barpubf{}
> class Barp{}
> class Barpp{}
> class Bar extends Foo {
>   Barp barp
>   public Barpubf barpubf
>   protected Integer barProtField = 150
>   Barpp getBarPseudoProp() { null }
>   void setBarPseudoProp(Barpp bpp) { }
> }
> class Bazpubf{}
> class Bazp{}
> class Bazpp{}
> @TupleConstructor(includeFields=true, includeSuperFields=true, includeSuperProperties=true)
> class Baz extends Bar {
>   Bazp bazp
>   public Bazpubf bazpubf
>   protected Long bazProtField = 2000L
>   Bazpp getBazPseudoProp() { null }
>   void setBazPseudoProp(Bazpp bpp) { }
> }
> Baz.constructors.each {
>     println it
> }
> {code}
> which produces:
> {code}
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf,java.lang.Long)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp,Bazpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer,Bazp)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf,java.lang.Integer)
> public Baz(Foop,Barp,Foopubf,java.lang.Short,Barpubf)
> public Baz(Foop,Barp,Foopubf,java.lang.Short)
> public Baz(Foop,Barp,Foopubf)
> public Baz(Foop,Barp)
> public Baz(Foop)
> public Baz()
> {code}
> Here, {{Barp}} is meant to be the 4th not 2nd param. This is a breaking change but I believe that {{includeSuperFields}} is rarely used and the two flags together perhaps slightly more so. Given that I am about to add JavaBean properties into the mix, it seems best to fix this now. The workaround for those requiring the old behavior is to add an {{includes}} annotation attribute and specify the required order. For the above example: {{includes='foop,barp,foopubf,...'}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)