Details

    • Type: Sub-task Sub-task
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0-RC-1
    • Fix Version/s: None
    • Component/s: groovy-runtime
    • Labels:
      None
    • Number of attachments :
      0

      Description

      If I declare a private field like this...

      Person.groovy
      class Person {
         private firstName
      }
      

      I can still access this field from another class like this...

      Foo.groovy
      class Foo {
         def doIt() {
             def p = new Person(firstName:'Jeff')
             println p.firstName
         }
         static void main(args) {
             new Foo().doIt()
         }
      }
      

      I don't think that I should be able to access p.firstName inside of the Foo class.

        Issue Links

          Activity

          Hide
          Mauro Molinari added a comment -

          Yes, but it doesn't make sense to have "private" keyword if it does nothing, does it? Personally I agree with those who think that "private" keyword should be honoured by default and ignored only if explicitly requested. The fact there are workarounds to violate the private visibility even in Java doesn't make "private" keyword useless.

          Show
          Mauro Molinari added a comment - Yes, but it doesn't make sense to have "private" keyword if it does nothing, does it? Personally I agree with those who think that "private" keyword should be honoured by default and ignored only if explicitly requested. The fact there are workarounds to violate the private visibility even in Java doesn't make "private" keyword useless.
          Hide
          CÚdric Champeau added a comment -

          At least, private documents the fact that the field or method is supposed to be internal and that it's better to avoid using it directly unless you have no other choice.

          I'm not saying that Groovy should not honor private modifiers semantics, I'm just saying that it's not a big deal, since there are always options, and easy ones, to bypass it. So it's definitely not a critical issue IMHO. The compiler could produce warnings, for example, that's already one level. You can ask it to throw errors only if you are using static type checking, because there's no way to know at compile time if a field is private or not. At runtime, using a new MOP, we could also enforce the semantics, but if you make it an option to be able to use private fields or not, then you are just making it a little more complicated to use that "feature", but you're still not enforcing anything.

          Last but not least, this "feature" is probably used in a lot of Groovy programs, so enforcing the semantics by default would probably break a lot of code.

          So, in the end, whatever we decide, we have to keep all this in mind.

          Show
          CÚdric Champeau added a comment - At least, private documents the fact that the field or method is supposed to be internal and that it's better to avoid using it directly unless you have no other choice. I'm not saying that Groovy should not honor private modifiers semantics, I'm just saying that it's not a big deal, since there are always options, and easy ones, to bypass it. So it's definitely not a critical issue IMHO. The compiler could produce warnings, for example, that's already one level. You can ask it to throw errors only if you are using static type checking, because there's no way to know at compile time if a field is private or not. At runtime, using a new MOP, we could also enforce the semantics, but if you make it an option to be able to use private fields or not, then you are just making it a little more complicated to use that "feature", but you're still not enforcing anything. Last but not least, this "feature" is probably used in a lot of Groovy programs, so enforcing the semantics by default would probably break a lot of code. So, in the end, whatever we decide, we have to keep all this in mind.
          Hide
          blackdrag blackdrag added a comment -

          GROOVY-1875 is about private properties, this here about a private field. So no duplicate but very related

          As for private not having an effect... that is not true, a subclass cannot access a private member. So it has an effect, even if it is only partially of what Java has/allows

          Show
          blackdrag blackdrag added a comment - GROOVY-1875 is about private properties, this here about a private field. So no duplicate but very related As for private not having an effect... that is not true, a subclass cannot access a private member. So it has an effect, even if it is only partially of what Java has/allows
          Hide
          Kenneth Endfinger added a comment -

          Duplicate of GROOVY-3010

          Show
          Kenneth Endfinger added a comment - Duplicate of GROOVY-3010
          Hide
          Jeff Scott Brown added a comment -

          Kenneth,

          This issue is currently categorized as a subtask of GROOVY-3010.

          Show
          Jeff Scott Brown added a comment - Kenneth, This issue is currently categorized as a subtask of GROOVY-3010 .

            People

            • Assignee:
              blackdrag blackdrag
              Reporter:
              Jeff Scott Brown
            • Votes:
              16 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated: