groovy
  1. groovy
  2. GROOVY-3284

Call behavior on enums is inconsistent

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.7
    • Fix Version/s: 1.6.1, 1.5.8, 1.7-beta-1
    • Component/s: None
    • Labels:
      None
    • Environment:
      XP, cygwin, JRE 1.6.0
    • Number of attachments :
      0

      Description

      A call method on an enum can be used within a for loop, but not otherwise. This is kind of odd, and it might be better to disable the for loop behavior if it's not reasonable to fix in general.

       
      
      enum Foo {
          A({ println("A") }),
          B({ println("B") })
          Foo(Closure c) {
            call = c
          }
          final Closure call
      }
      
      // works
      for (f in Foo) {
         f()
      }
      
      // works
      Foo.A.call()
      
      // doesn't work
      Foo.A()
      
      // doesn't work
      a=Foo.A
      a()
      

        Activity

        Hide
        blackdrag blackdrag added a comment -

        for your issue 1: the static method supersedes the call convention. So yes.. if there is a static method A, then it should be called instead of doing Foo.A.call()

        for issue 2: I think this is a workaround, but why letting have them define a local variable just for that? It would be better to then simply write Foo.A.call() then instead, or not? For DSLs it is better if it works without the workaround.

        If you are going to do the fix as I suggested, then the potential impact is unclear to me. I would probably put that not into 1.5.x or 1.6.x, but only into 1.7, because of that.

        Show
        blackdrag blackdrag added a comment - for your issue 1: the static method supersedes the call convention. So yes.. if there is a static method A, then it should be called instead of doing Foo.A.call() for issue 2: I think this is a workaround, but why letting have them define a local variable just for that? It would be better to then simply write Foo.A.call() then instead, or not? For DSLs it is better if it works without the workaround. If you are going to do the fix as I suggested, then the potential impact is unclear to me. I would probably put that not into 1.5.x or 1.6.x, but only into 1.7, because of that.
        Hide
        Roshan Dawrani added a comment -

        Ok, I will first undo my changes from the 3 branches and then try to fix it as you have suggested.

        And then if I am solve it that way, I will have the patch reviewed first and do the changes only on 1.7.

        Show
        Roshan Dawrani added a comment - Ok, I will first undo my changes from the 3 branches and then try to fix it as you have suggested. And then if I am solve it that way, I will have the patch reviewed first and do the changes only on 1.7.
        Hide
        blackdrag blackdrag added a comment -

        ok

        Show
        blackdrag blackdrag added a comment - ok
        Hide
        Roshan Dawrani added a comment -

        Undid the changes made earlier.

        Show
        Roshan Dawrani added a comment - Undid the changes made earlier.
        Hide
        Roshan Dawrani added a comment -

        Resolved.

        Applied the new, reviewed fix on the branches 1.5.x, 1.6.x and trunk.

        Show
        Roshan Dawrani added a comment - Resolved. Applied the new, reviewed fix on the branches 1.5.x, 1.6.x and trunk.

          People

          • Assignee:
            Roshan Dawrani
            Reporter:
            Chris Currivan
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: