groovy
  1. groovy
  2. GROOVY-3467

Boolean assignment optimized by compiler

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6
    • Fix Version/s: 2.0-rc-3
    • Component/s: Compiler
    • Labels:
      None
    • Environment:
      groovyConsole 1.6.0
    • Number of attachments :
      1

      Description

      I think the attached script should pass. Specifically this line:

      X = [Y, Z]

      should go through setProperty("X", [null, null]) but instead it comes in as setProperty("X", true)

      I am using this feature for a DSL to define the rules for a binary decision tree.

      Added to the compiler because of this email on the list:
      http://tinyurl.com/cfuyah

        Activity

        Hide
        Roshan Dawrani added a comment -

        In a slightly smaller version, the issue is reproducible in the code below too:

        class Rule {
           Boolean X,Y,Z
           def rules = {
              X = [Y, Z]
            }
           void setProperty(String n, v) {
               println "n = $n, v = $v" // prints n = X, v = true
           }
        }
        
        new Rule().rules()
        
        Show
        Roshan Dawrani added a comment - In a slightly smaller version, the issue is reproducible in the code below too: class Rule { Boolean X,Y,Z def rules = { X = [Y, Z] } void setProperty( String n, v) { println "n = $n, v = $v" // prints n = X, v = true } } new Rule().rules()
        Hide
        Roshan Dawrani added a comment -

        Is this really a bug? I guess, it can be looked at both ways.

        Why is not ok in "Boolean X = [Y, Z]" that first RHS is evaluated in the context of type of LHS and then the evaluated value undergoes the setProperty() mechanism?

        If the compiler is not do the type conversion in this case, then whose responsibility is it - setProperty() should explicitly handle the type conversion itself?

        Show
        Roshan Dawrani added a comment - Is this really a bug? I guess, it can be looked at both ways. Why is not ok in "Boolean X = [Y, Z] " that first RHS is evaluated in the context of type of LHS and then the evaluated value undergoes the setProperty() mechanism? If the compiler is not do the type conversion in this case, then whose responsibility is it - setProperty() should explicitly handle the type conversion itself?
        Hide
        blackdrag blackdrag added a comment -

        setProperty should get the list. But the setter for X should do the type conversion... well, the meta class, that calls the setter should do that.

        Show
        blackdrag blackdrag added a comment - setProperty should get the list. But the setter for X should do the type conversion... well, the meta class, that calls the setter should do that.
        Hide
        Roshan Dawrani added a comment -

        So, as a general rule, type conversion should be removed from compiler - for assignments? To change it from compile-time wiring to run-time handling (through meta-classes)? Or, am I not following you?

        Show
        Roshan Dawrani added a comment - So, as a general rule, type conversion should be removed from compiler - for assignments? To change it from compile-time wiring to run-time handling (through meta-classes)? Or, am I not following you?
        Hide
        blackdrag blackdrag added a comment -

        no, there is also field=foo, in that case the compiler usually generates code, that will directly set the field, in which case the conversion has to be done by the compiler too

        Show
        blackdrag blackdrag added a comment - no, there is also field=foo, in that case the compiler usually generates code, that will directly set the field, in which case the conversion has to be done by the compiler too
        Hide
        blackdrag blackdrag added a comment -

        After looking at this again my last comment actually makes no sense. It is true that for code in a class we don't go trough setProperty and thus the compiler has to do those things. But here it is code from a closure and that code indeed goes through the setProperty call.

        To have the compiler base transformations and the ones done for direct field access it would actually be good to always let the compiler do that. But then the compiler needs to know the type and if it is not X=, but foo.X=, then it is most probably not the case and the setter code will have to do the conversion anyway.

        So I think setProperty should get the list in that case.

        Show
        blackdrag blackdrag added a comment - After looking at this again my last comment actually makes no sense. It is true that for code in a class we don't go trough setProperty and thus the compiler has to do those things. But here it is code from a closure and that code indeed goes through the setProperty call. To have the compiler base transformations and the ones done for direct field access it would actually be good to always let the compiler do that. But then the compiler needs to know the type and if it is not X=, but foo.X=, then it is most probably not the case and the setter code will have to do the conversion anyway. So I think setProperty should get the list in that case.
        Hide
        blackdrag blackdrag added a comment -

        I didn't check since when exactly this issue has been fixed, but it seems that current Groovy does not longer show this behaviour. Thus I close the issue as fixed

        Show
        blackdrag blackdrag added a comment - I didn't check since when exactly this issue has been fixed, but it seems that current Groovy does not longer show this behaviour. Thus I close the issue as fixed

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            zak jacobson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: