Details

    • Type: Sub-task Sub-task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.x
    • Component/s: groovy-runtime
    • Labels:
      None
    • Number of attachments :
      1

      Description

      We should make it possible to implement any Java interface with method missing:

      class Foo {
          def methodMissing(String name, args) { null }
      }
      
      def f = new Foo()
      def ctx = f as SomeInterface
      

      The proxy would simply delegate from the interface through methodMissing

        Activity

        Hide
        Andres Almiray added a comment -

        What is the rationale for this feature?

        Show
        Andres Almiray added a comment - What is the rationale for this feature?
        Hide
        Steve Ardis 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

        Show
        Steve Ardis 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
        Hide
        Steve Ardis added a comment -

        GroovyInterfaceTests added (see comment by Steve Ardis on 10/23/2009 for reference).

        Show
        Steve Ardis added a comment - GroovyInterfaceTests added (see comment by Steve Ardis on 10/23/2009 for reference).
        Hide
        blackdrag blackdrag added a comment -

        I updated the title to better reflect the issue. In the example the method c is implemented by the mixin, but since the current mixin logic use almost only runtime, there will be no c method generated, thus there is an abstract method, that needs to be implemented.

        What should happen is, that the method gets implemented through the mixin

        Show
        blackdrag blackdrag added a comment - I updated the title to better reflect the issue. In the example the method c is implemented by the mixin, but since the current mixin logic use almost only runtime, there will be no c method generated, thus there is an abstract method, that needs to be implemented. What should happen is, that the method gets implemented through the mixin

          People

          • Assignee:
            Unassigned
            Reporter:
            Graeme Rocher
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: