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