You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (JIRA)" <ji...@apache.org> on 2018/01/22 00:33:00 UTC
[jira] [Updated] (GROOVY-8455) @TupleConstructor gives wrong
ordering when includeSuperFields is set
[ https://issues.apache.org/jira/browse/GROOVY-8455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul King updated GROOVY-8455:
------------------------------
Description:
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,...'}}.
was:
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'}}.
> @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)