groovy
  1. groovy
  2. GROOVY-3395

calling binding variable as function fails to try object's call() method

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.6
    • Fix Version/s: 3.0
    • Component/s: groovy-runtime
    • Labels:
      None
    • Environment:
      Red Hat Linux 5 with groovy 1.6.0 binary distribution; also reproduced on Debian 5.0
    • Number of attachments :
      1

      Description

      From a script, if x is a variable in the binding, calling x() appears not to try calling x's call method, at least in some cases. (It does work for closures, though.) The following example code illustrates the behavior fully. When running the code, it catches the MissingMethodException and print "oops – didn't try c1.call()".

      If this is intended behavior, I'd appreciate an explanation. I apologize if this is known. I searched JIRA but didn't find anything. I suspect my indentation will not be preserved here...

      class Callable
      {
          Object call()
          {
              'Callable.call'
          }
      }
      
      Callable c = new Callable()
      assert 'Callable.call' == c()
      
      def binding = new Binding()
      binding.c1 = c
      binding.c2 = { c() }
      def shell = new GroovyShell(binding)
      try
      {
          assert 'Callable.call' == shell.evaluate('c1()')
      }
      catch (MissingMethodException)
      {
          println "oops -- didn't try c1.call()"
      }
      assert 'Callable.call' == shell.evaluate('c1.call()')
      assert 'Callable.call' == shell.evaluate('c2()')
      

        Activity

        Hide
        Jay Berkenbilt added a comment -

        Yes, my formatting was completely mangled. I'm also going to attach the code. (Is there a way to prevent JIRA from doing this?)

        Show
        Jay Berkenbilt added a comment - Yes, my formatting was completely mangled. I'm also going to attach the code. (Is there a way to prevent JIRA from doing this?)
        Hide
        Jay Berkenbilt added a comment -

        Here's the same code as posted in the body of the bug report.

        Show
        Jay Berkenbilt added a comment - Here's the same code as posted in the body of the bug report.
        Hide
        blackdrag blackdrag added a comment -

        added code tags for better fromatting

        Show
        blackdrag blackdrag added a comment - added code tags for better fromatting
        Hide
        blackdrag blackdrag added a comment -

        currently a local variable can be of any type to and called as if it were a function by for example c(). In case of properties we decided to limit this to Closure instances, because properties and methods share the same name space here and if there would be a method of the same name, then we have a problem. We could in general call the property, but then what is if it doesn't have the call method? fall back to the other method being called?

        Show
        blackdrag blackdrag added a comment - currently a local variable can be of any type to and called as if it were a function by for example c(). In case of properties we decided to limit this to Closure instances, because properties and methods share the same name space here and if there would be a method of the same name, then we have a problem. We could in general call the property, but then what is if it doesn't have the call method? fall back to the other method being called?
        Hide
        blackdrag blackdrag added a comment -

        I setting the fix version to 2.0 because I think that we should look at that bug, when the MOP is refreshed. I think a request based MOP can solve this problem without big performance loss by asking the meta class of the property if it has such a method. And if not, fall back to the normal method call

        Show
        blackdrag blackdrag added a comment - I setting the fix version to 2.0 because I think that we should look at that bug, when the MOP is refreshed. I think a request based MOP can solve this problem without big performance loss by asking the meta class of the property if it has such a method. And if not, fall back to the normal method call
        Hide
        blackdrag blackdrag added a comment -

        for 2.0 we also need to think about what we do if here is a call method, but the arguments don't fit. In case of a closure we still do the call provoking a MethodSelectionException.

        Show
        blackdrag blackdrag added a comment - for 2.0 we also need to think about what we do if here is a call method, but the arguments don't fit. In case of a closure we still do the call provoking a MethodSelectionException.
        Hide
        Roshan Dawrani added a comment -

        I am not able to reproduce the issue on both 1.6.x and trunk (Windows XP + jdk 1.5). It runs fine without printing "oops – didn't try c1.call()"

        Show
        Roshan Dawrani added a comment - I am not able to reproduce the issue on both 1.6.x and trunk (Windows XP + jdk 1.5). It runs fine without printing "oops – didn't try c1.call()"
        Hide
        Kirill Vergun added a comment - - edited

        Gosh! I wanted to make all my fields callable!
        Any news about 3.0 and fixes?

        Windows 7, JDK 1.7, Groovy 2.2.2

        Show
        Kirill Vergun added a comment - - edited Gosh! I wanted to make all my fields callable! Any news about 3.0 and fixes? Windows 7, JDK 1.7, Groovy 2.2.2

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Jay Berkenbilt
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: