[jira] [Updated] (GROOVY-8864) Backwards compatibility of traits
[ https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King updated GROOVY-8864: -- Affects Version/s: 2.5.3 > Backwards compatibility of traits > - > > Key: GROOVY-8864 > URL: https://issues.apache.org/jira/browse/GROOVY-8864 > Project: Groovy > Issue Type: Task >Affects Versions: 2.5.3 >Reporter: Paul King >Assignee: Paul King >Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.4 > > > In Groovy 2.4 we allow: > {code} > trait Foo { > static T get() { > ... > } > } > class Bar implements Foo {} > assert Bar.getMethod("get").returnType.name == 'Bar' > {code} > This produces some useful type information in the generated class: > {code} > class Bar implements Foo { > ... > static Bar get() { > ((Foo$Trait$Helper.get(this)) as Bar) > } > ... > } > {code} > It's a little strange in that a spurious generics type appears in the trait > helper class for 2.4 but we ignore it: > {code} > static java.lang.Object get(java.lang.Class $static$self) { > ... > } > {code} > In 2.5, we tightened this up to behave more like Java where you can't use a > class's generic type parameters in static methods or static fields. However, > a trait isn't a class but rather a mechanism for creating classes. > This issue is to look at whether we can provide the 2.4 benefit of having > type information in the generated class but avoid any spurious generics info > appearing where it shouldn't. > As some additional information, the following example shows that even in 2.4, > not all cases worked: > {code} > trait Foo { > static T get() { ... } > } > class Baz implements Foo {} > def bz = new Baz() > assert bz.getClass().getMethod("get").returnType == Object > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GROOVY-8864) Backwards compatibility of traits
[ https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Milles updated GROOVY-8864: Labels: traits (was: ) > Backwards compatibility of traits > - > > Key: GROOVY-8864 > URL: https://issues.apache.org/jira/browse/GROOVY-8864 > Project: Groovy > Issue Type: Task >Affects Versions: 2.5.3 >Reporter: Paul King >Assignee: Paul King >Priority: Major > Labels: traits > Fix For: 3.0.0-alpha-4, 2.5.4 > > > In Groovy 2.4 we allow: > {code} > trait Foo { > static T get() { > ... > } > } > class Bar implements Foo {} > assert Bar.getMethod("get").returnType.name == 'Bar' > {code} > This produces some useful type information in the generated class: > {code} > class Bar implements Foo { > ... > static Bar get() { > ((Foo$Trait$Helper.get(this)) as Bar) > } > ... > } > {code} > It's a little strange in that a spurious generics type appears in the trait > helper class for 2.4 but we ignore it: > {code} > static java.lang.Object get(java.lang.Class $static$self) { > ... > } > {code} > In 2.5, we tightened this up to behave more like Java where you can't use a > class's generic type parameters in static methods or static fields. However, > a trait isn't a class but rather a mechanism for creating classes. > This issue is to look at whether we can provide the 2.4 benefit of having > type information in the generated class but avoid any spurious generics info > appearing where it shouldn't. > As some additional information, the following example shows that even in 2.4, > not all cases worked: > {code} > trait Foo { > static T get() { ... } > } > class Baz implements Foo {} > def bz = new Baz() > assert bz.getClass().getMethod("get").returnType == Object > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)