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/10/31 08:13:00 UTC
[jira] [Created] (GROOVY-8864) Backwards compatibility of traits
Paul King created GROOVY-8864:
---------------------------------
Summary: Backwards compatibility of traits
Key: GROOVY-8864
URL: https://issues.apache.org/jira/browse/GROOVY-8864
Project: Groovy
Issue Type: Task
Reporter: Paul King
In Groovy 2.4 we allow:
{code}
trait Foo<T> {
static T get() {
...
}
}
class Bar implements Foo<Bar> {}
assert Bar.getMethod("get").returnType.name == 'Bar'
{code}
This produces some useful type information in the generated class:
{code}
class Bar implements Foo<Bar> {
...
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<T> get(java.lang.Class<Foo> $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<T> {
static T get() { ... }
}
class Baz<E> implements Foo<E> {}
def bz = new Baz<String>()
assert bz.getClass().getMethod("get").returnType == Object
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)