Details

    • Type: Sub-task Sub-task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1-beta-1
    • Fix Version/s: None
    • Component/s: class generator
    • Labels:
      None
    • Environment:
      Windows XP - Java 1.6.0 - Groovy 1.1-beta-1
    • Number of attachments :
      0

      Description

      class Test {
      private text
      private def getText()

      { text.toUpperCase() }

      private void setText( text )

      { this.text = text * 10 }

      }

      using the previous class with the following script

      x = new Test()
      x.text = "z"
      println x.text

      give the result: "ZZZZZZZZZZ"

        Issue Links

          Activity

          Hide
          blackdrag blackdrag added a comment -

          true, there is a "fromInside" on MetaClass. I added that a long while ago. But later I did see that this does not solve the issue at all. In a class if you have "this.foo", then it is compiled as direct field access if the field exists. If you do only "foo", then due to the implicit "this", it is compiled in the same way as "this.foo". That means that in current Groovy (1.0, 1.5.x, 1.6) the MetaClass method won't be used for this and a direct field access, like Java would do that is done instead. We can do this for classes, because classes have a clear context when it comes to the meaning of the implicit "this". Much later than adding this parameter we decided on two things, first the direct access to the field in classes and second the mutable name resolving for closures. That all opens a bug question for when then implicit this means "this" as in a class or the delegate.. not to forget that there is the problem that a closure should ask the owner for the field, not the class directly in the nested case. And now it comes down to the MOP. If we don't do a direct field access, then we need to go through the MOP. And that unfortunately means to do a property based access, because the current MOP does not have a special case for fields only. We also have the convention, that "this.foo" becomes a property access if there is no field foo. As a conclusion every field/property access becomes a MOP based property access inside a closure, because we don't know the real meaning of the "implicit this" until runtime.

          Now the next element... doing a property based MOP access means that you have to go through getProperty first. And if you look at that method, then you will see, that getProperty doesnot provide this "fromInside" flag. And since that information is mssing, it can't be given to MetaClass and there used to restrict access.

          Solutions? one might be to extend getProperty -> breaking change to the MOP. Another to resolve fields in Closures directly while assuming the "implicit this" means the class the closure is contained in -> breaking change to how names are resolved in Closures and the MOP probably as well.

          Since there goes no solution without a breaking change I do not want to do this before 2.0

          Show
          blackdrag blackdrag added a comment - true, there is a "fromInside" on MetaClass. I added that a long while ago. But later I did see that this does not solve the issue at all. In a class if you have "this.foo", then it is compiled as direct field access if the field exists. If you do only "foo", then due to the implicit "this", it is compiled in the same way as "this.foo". That means that in current Groovy (1.0, 1.5.x, 1.6) the MetaClass method won't be used for this and a direct field access, like Java would do that is done instead. We can do this for classes, because classes have a clear context when it comes to the meaning of the implicit "this". Much later than adding this parameter we decided on two things, first the direct access to the field in classes and second the mutable name resolving for closures. That all opens a bug question for when then implicit this means "this" as in a class or the delegate.. not to forget that there is the problem that a closure should ask the owner for the field, not the class directly in the nested case. And now it comes down to the MOP. If we don't do a direct field access, then we need to go through the MOP. And that unfortunately means to do a property based access, because the current MOP does not have a special case for fields only. We also have the convention, that "this.foo" becomes a property access if there is no field foo. As a conclusion every field/property access becomes a MOP based property access inside a closure, because we don't know the real meaning of the "implicit this" until runtime. Now the next element... doing a property based MOP access means that you have to go through getProperty first. And if you look at that method, then you will see, that getProperty doesnot provide this "fromInside" flag. And since that information is mssing, it can't be given to MetaClass and there used to restrict access. Solutions? one might be to extend getProperty -> breaking change to the MOP. Another to resolve fields in Closures directly while assuming the "implicit this" means the class the closure is contained in -> breaking change to how names are resolved in Closures and the MOP probably as well. Since there goes no solution without a breaking change I do not want to do this before 2.0
          Hide
          Victor Volle added a comment -

          Fix Version/s: None?

          Show
          Victor Volle added a comment - Fix Version/s: None?
          Hide
          blackdrag blackdrag added a comment -

          it is now a subtask of GROOVY-3010, which is scheduled for 2.0. GROOVY-3010 is a task and has several sub tasks, to collect the issues which are more or less the same.

          Show
          blackdrag blackdrag added a comment - it is now a subtask of GROOVY-3010 , which is scheduled for 2.0. GROOVY-3010 is a task and has several sub tasks, to collect the issues which are more or less the same.
          Hide
          Daniel.Sun added a comment -

          It seems that groovy++ has resolved the issue. Maybe Alex Tkachman can give a hand to port the code.

          Show
          Daniel.Sun added a comment - It seems that groovy++ has resolved the issue. Maybe Alex Tkachman can give a hand to port the code.
          Hide
          Kenneth Endfinger added a comment -

          Duplicate of GROOVY-3010

          Show
          Kenneth Endfinger added a comment - Duplicate of GROOVY-3010

            People

            • Assignee:
              blackdrag blackdrag
              Reporter:
              Louis Martin
            • Votes:
              35 Vote for this issue
              Watchers:
              25 Start watching this issue

              Dates

              • Created:
                Updated: