|
ah - there's a problem though:
abstract class Numeric { class Rational extends Numeric { this would have Groovy complaining that eval() in Numeric is not implemented 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.
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 ...it is important that groovyc maintain the generics information when it compiles the class. 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 as commented in
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
support covariant return types (& generics)
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!