added a comment - - edited
My scenario is this. I'm using Grails 1.2-M3, which depends on Groovy 1.6.4. I'm also using the Grails Remoting Plugin, which requires an interface.
What I would like to be able to do is create methods on an interface, parse them in methodmissing(..) and in-turn invoke the appropriate method on the GORM object.
For example:
UserServiceIF.java:
interface UserServiceIF { User findUserByUsername(String username); }
UserService.groovy:
@Mixin(DAOMixin)
class UserService implements UserServiceIF {
}
DAOMixin.groovy:
class DAOMixin {
def methodMissing(String name, args) {
...
// parse GORM object name and method
// return User.findByUsername(username)
}
}
I've dumbed this scenario down to the attached file - GroovyInterfaceTests.groovy – NOTE!! You have to uncomment the c() and d() methods from the interface to get the compilation error.
I know there was a JIRA issue to fix this already for @Delegate in Groovy 1.6.4 - its functionality is verified in the provided test case.
My belief is that no Groovy class should ever have an issue with "Can't have an abstract method in a non-abstract class." during compilation. Instead, the Groovy compiler should check for methods provided through any @Delegate or @Mixin; if methods are still missing on the class, the compiler should dynamically create the method on the class and invoke methodmissing(..).
I'll admit I have no background with writing compilers and have no knowledge to the feasibility of this - it just feels like it should be able to happen.
Thanks -
Steve Ardis
New Feature
Open
Major
What is the rationale for this feature?