groovy

fix private field visibility

Details

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

Description

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

Issue Links

This issue relates to:
GROOVY-2433 Closure in base class unable to call private methods when invoked from derived class Major Open
This issue is related to:
GROOVY-3142 Unable to access inherited private fields from a closure within an inherited method Major Open
This issue is depended upon by:
GROOVY-3073 Private inheritance bug: Closure accessing private method Major Open
GROOVY-2503 MOP 2.0 design inflluencing issues Major Open

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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.

People

Vote (16)
Watch (15)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.