groovy

support covariant return types (& generics)

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-JSR-5
  • Fix Version/s: 1.1-rc-1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    1

Description

CRT is really useful, even if Generics is not fully supported / implemented

Issue Links

This issue is duplicated by:
GROOVY-1860 Problem calling override method with different return type. Blocker Closed
This issue depends upon:
GROOVY-1962 add a stream based class reader and an optional java5 module Blocker Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

covariant return types means usually to have two method withe the same name and the same parameter types, but diefferent return types. Groovy does support this already:

class A{
void foo(){}
Object foo(){}

}

A.class.declaredMethods.each{println it}

and you get:
public void A.setProperty(java.lang.String,java.lang.Object)
public java.lang.Object A.getProperty(java.lang.String)
public java.lang.Object A.invokeMethod(java.lang.String,java.lang.Object)
public groovy.lang.MetaClass A.getMetaClass()
public void A.setMetaClass(groovy.lang.MetaClass)
static java.lang.Class A.class$(java.lang.String)
public void A.foo()
public java.lang.Object A.foo()

there are 2 foo methods, so the methods are there. To do it like java means to let one of it redirect to the other automatically. This part is missing, yes.

btw, you can only call only one of these methods!

Show
blackdrag blackdrag added a comment - covariant return types means usually to have two method withe the same name and the same parameter types, but diefferent return types. Groovy does support this already: class A{ void foo(){} Object foo(){} } A.class.declaredMethods.each{println it} and you get: public void A.setProperty(java.lang.String,java.lang.Object) public java.lang.Object A.getProperty(java.lang.String) public java.lang.Object A.invokeMethod(java.lang.String,java.lang.Object) public groovy.lang.MetaClass A.getMetaClass() public void A.setMetaClass(groovy.lang.MetaClass) static java.lang.Class A.class$(java.lang.String) public void A.foo() public java.lang.Object A.foo() there are 2 foo methods, so the methods are there. To do it like java means to let one of it redirect to the other automatically. This part is missing, yes. btw, you can only call only one of these methods!
Hide
Permalink
Alex Lam S.L. added a comment -

ah - there's a problem though:

abstract class Numeric {
abstract Numeric eval();
}

class Rational extends Numeric {
Rational eval() {
this
}
}

this would have Groovy complaining that eval() in Numeric is not implemented

Show
Alex Lam S.L. added a comment - ah - there's a problem though: abstract class Numeric { abstract Numeric eval(); } class Rational extends Numeric { Rational eval() { this } } this would have Groovy complaining that eval() in Numeric is not implemented
Hide
Permalink
blackdrag blackdrag added a comment -

I think, to fully support this we have to generate 1.5 bytecode. We decided not to do this before 1.0, so this does have to wait. After 1.0 we will have to discuss how we support generics.

Show
blackdrag blackdrag added a comment - I think, to fully support this we have to generate 1.5 bytecode. We decided not to do this before 1.0, so this does have to wait. After 1.0 we will have to discuss how we support generics.
Hide
Permalink
Kennard Consulting added a comment -

Please note that even if Groovy decides to ignore generics because it is already a dynamically typed language, it is still important that it generate the correct 1.5 generics bytecode, including all the generics metadata.

Even after erasure, there is still a good deal of generics metadata present in the bytecode of Classes, Methods and Fields, and many significant frameworks (JPA, Spring) depend on this.

A prominent use case would be trying to define an EJB3 entity bean using GroovyBeans...

@Entity
class Foo
{
@OneToMany
Set<Bar> bars;
}

...it is important that groovyc maintain the generics information when it compiles the class.

Show
Kennard Consulting added a comment - Please note that even if Groovy decides to ignore generics because it is already a dynamically typed language, it is still important that it generate the correct 1.5 generics bytecode, including all the generics metadata. Even after erasure, there is still a good deal of generics metadata present in the bytecode of Classes, Methods and Fields, and many significant frameworks (JPA, Spring) depend on this. A prominent use case would be trying to define an EJB3 entity bean using GroovyBeans... @Entity class Foo { @OneToMany Set<Bar> bars; } ...it is important that groovyc maintain the generics information when it compiles the class.
Hide
Permalink
Emmanuel added a comment -

Here is an example of useful inheritance of Generics, including test case. drop it in src/test/groovy/tiger
As Kennard pointed out, it's something important to achieve a friendly integration with JavaEE and their frameworks, esp JPA

Show
Emmanuel added a comment - Here is an example of useful inheritance of Generics, including test case. drop it in src/test/groovy/tiger As Kennard pointed out, it's something important to achieve a friendly integration with JavaEE and their frameworks, esp JPA
Hide
Permalink
blackdrag blackdrag added a comment -

as commented in GROOVY-1860 a bigger refactoring is needed here, so I will have it postponed to beta-3

Show
blackdrag blackdrag added a comment - as commented in GROOVY-1860 a bigger refactoring is needed here, so I will have it postponed to beta-3
Hide
Permalink
blackdrag blackdrag added a comment -

fixed

Show
blackdrag blackdrag added a comment - fixed

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.