Details

    • Type: Task Task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: groovy-runtime
    • Labels:
      None
    • Number of attachments :
      1

      Description

      this task collects all the issues related to a privae field being visible, when it should not be visible

        Issue Links

          Activity

          Hide
          Michael Kebe added a comment -

          I just read Neal Ford's book "The Productive Programmer". And in chapter 12 "Meta-Programming" he just picked this bug to show testing a private method of Java with Groovy. Here is a quote:

          Technically, this is a bug in Groovy (that has been there since day one), but it's so insanely useful, no one has bothered to fix it. And I hope they never do. In any language with strong reflection capabilities, the private keyword is not much more than documentation anyway: I can always use reflection to get to it if the need arises.

          Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?

          Show
          Michael Kebe added a comment - I just read Neal Ford's book "The Productive Programmer". And in chapter 12 "Meta-Programming" he just picked this bug to show testing a private method of Java with Groovy. Here is a quote: Technically, this is a bug in Groovy (that has been there since day one), but it's so insanely useful, no one has bothered to fix it. And I hope they never do. In any language with strong reflection capabilities, the private keyword is not much more than documentation anyway: I can always use reflection to get to it if the need arises. Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?
          Hide
          Merlyn Albery-Speyer added a comment -

          Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases?

          It'd be easy enough to provide a declarative-style way of suppressing access checks while executing a closure.

          Personally, I think that the @ convention for bypassing access protection is in line with other features Groovy offers such as redefining the methods of other classes.

          Show
          Merlyn Albery-Speyer added a comment - Maybe there is a way to give the testing community an option to allow the access of private methods/fields in testcases? It'd be easy enough to provide a declarative-style way of suppressing access checks while executing a closure. Personally, I think that the @ convention for bypassing access protection is in line with other features Groovy offers such as redefining the methods of other classes.
          Hide
          Donal Murtagh added a comment -

          I might be wrong but I thought @ was for accessing (from within a class) a private field 'foo' when the class also has a public property named 'foo', i.e. it provides a way to disambiguate between a private field and public property of the same name.

          I disagree with the statement from Neal Ford's book. While this bug is useful if you only want to use Groovy to test or script Java apps, if you want to build robust production apps in Groovy, this bug makes it impossible to protect a class' invariants.

          Show
          Donal Murtagh added a comment - I might be wrong but I thought @ was for accessing (from within a class) a private field 'foo' when the class also has a public property named 'foo', i.e. it provides a way to disambiguate between a private field and public property of the same name. I disagree with the statement from Neal Ford's book. While this bug is useful if you only want to use Groovy to test or script Java apps, if you want to build robust production apps in Groovy, this bug makes it impossible to protect a class' invariants.
          Hide
          Serg Lifinsky added a comment -

          Example hoto implement private methods and properties in javasxript using wrap method

          Show
          Serg Lifinsky added a comment - Example hoto implement private methods and properties in javasxript using wrap method
          Hide
          Paul King added a comment -

          @Serg: your example is nice but how is it related to the issue in Groovy.

          Show
          Paul King added a comment - @Serg: your example is nice but how is it related to the issue in Groovy.
          Hide
          Serg Lifinsky added a comment -

          Using closure as wrap method in example and control call to private method. Only in wrapers for protected and public methods we set caller as current class, and in wrapper for private method validate that caller is current class

          Show
          Serg Lifinsky added a comment - Using closure as wrap method in example and control call to private method. Only in wrapers for protected and public methods we set caller as current class, and in wrapper for private method validate that caller is current class
          Hide
          Serg Lifinsky added a comment -

          If class already have private method which work with private property, do not generate default getter/setter for this private property. Hot fix

          Show
          Serg Lifinsky added a comment - If class already have private method which work with private property, do not generate default getter/setter for this private property. Hot fix
          Hide
          Antoine Roux added a comment -

          Private is definitely something missing. Sometimes I really to protect some field or method. Today, I encountered a piece of code that was calling a private method of a another class. It went unnoticed during years, until someone started working on it again. Luckily, he saw this error before changing anything.

          My point of view is that event tests should not access private members. But this is only me. A good alternative would be to have a special operator to indicate that you want to access a member without applying the rights. That would at the same time preserve this "feature" for people who need it while making it clear to everyone that the code is doing something special.

          I'd rather spend time one my code finding all the places where an illegal access to private members is done than keep this bug that allows such an dangerous behaviour.

          Show
          Antoine Roux added a comment - Private is definitely something missing. Sometimes I really to protect some field or method. Today, I encountered a piece of code that was calling a private method of a another class. It went unnoticed during years, until someone started working on it again. Luckily, he saw this error before changing anything. My point of view is that event tests should not access private members. But this is only me. A good alternative would be to have a special operator to indicate that you want to access a member without applying the rights. That would at the same time preserve this "feature" for people who need it while making it clear to everyone that the code is doing something special. I'd rather spend time one my code finding all the places where an illegal access to private members is done than keep this bug that allows such an dangerous behaviour.

            People

            • Assignee:
              Unassigned
              Reporter:
              blackdrag blackdrag
            • Votes:
              32 Vote for this issue
              Watchers:
              33 Start watching this issue

              Dates

              • Created:
                Updated: