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)