groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (GROOVY-8864) Backwards compatibility of traits
Date Fri, 02 Nov 2018 06:53:00 GMT

     [ https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul King resolved GROOVY-8864.
-------------------------------
       Resolution: Fixed
         Assignee: Paul King
    Fix Version/s: 2.5.4
                   3.0.0-alpha-4

I have made our extra checks on generics not apply to traits. This retains the desired behavior
from Groovy 2.4.  I think we should look to improving the underlying approach to achieve this
behavior since it is relying on generics information existing within the helper class that
wouldn't be allowed for Java. It isn't a problem with existing JDKs but could leave us exposed
if the strictness of class checking changed in future versions.

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

Mime
View raw message