groovy

Superclass can access field declared in subclass

Details

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

Description

Why does something like that work?

class Base {
  String test() {
     return subClassField   // subClassField is unknown in class Base!!
  }
}

class Sub extends Base {
  
  private subClassField = "foo"
  
  static main(args) {
     println new Sub().test() // -> "foo"
  }
}

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Torsten Feig added a comment -

Hm, the formatting of the code got lost somewhat, but I guess you can figure out how it was meant to be

Show
Torsten Feig added a comment - Hm, the formatting of the code got lost somewhat, but I guess you can figure out how it was meant to be
Hide
Permalink
blackdrag blackdrag added a comment -

added code tags

Show
blackdrag blackdrag added a comment - added code tags
Hide
Permalink
blackdrag blackdrag added a comment -

Why does this work? In short: because there is a design error in the Groovy runtime, which allows access to private fields in many cases. If it where a normal property, then the code would be ok, because it is allowed for a property or method in a subclass to become visible in the super class if they are not private. This works for methods well, but it seems for fields we have a bug.

I added this to 2.0 for now, since I am not sure it is possible to fix the issue without the work for GROOVY-3010 and its sub tasks.

Show
blackdrag blackdrag added a comment - Why does this work? In short: because there is a design error in the Groovy runtime, which allows access to private fields in many cases. If it where a normal property, then the code would be ok, because it is allowed for a property or method in a subclass to become visible in the super class if they are not private. This works for methods well, but it seems for fields we have a bug. I added this to 2.0 for now, since I am not sure it is possible to fix the issue without the work for GROOVY-3010 and its sub tasks.
Hide
Permalink
Torsten Feig added a comment -

Looking at programming language semantics in general, the behaviour you describe as "allowed" seems strange to me at least.
Can you point me to a corresponding specification in the groovy documentation? Before I entered the bug I searched the docs (and in the book "Groovy in Action" for something addressing this visibility/inheritance issue, but found nothing.

Show
Torsten Feig added a comment - Looking at programming language semantics in general, the behaviour you describe as "allowed" seems strange to me at least. Can you point me to a corresponding specification in the groovy documentation? Before I entered the bug I searched the docs (and in the book "Groovy in Action" for something addressing this visibility/inheritance issue, but found nothing.
Hide
Permalink
blackdrag blackdrag added a comment -

it is not easy to find documentation that describes exactly this.... because here several factors work together.

  1. a property access to a non existing property like subClassField in Base is handled by the runtime as access to the current meta class, which may or may not have the property.
  2. sub is adding th property subClassField to the meta class, thus when Base is asking for that property the call will succeed.

Part of this can be found in http://groovy.codehaus.org/Groovy+Beans Maybe not the ideal place.

What seems to be missing is a chapter about multimethods... which I will add soon

Show
blackdrag blackdrag added a comment - it is not easy to find documentation that describes exactly this.... because here several factors work together. a property access to a non existing property like subClassField in Base is handled by the runtime as access to the current meta class, which may or may not have the property. sub is adding th property subClassField to the meta class, thus when Base is asking for that property the call will succeed. Part of this can be found in http://groovy.codehaus.org/Groovy+Beans Maybe not the ideal place. What seems to be missing is a chapter about multimethods... which I will add soon

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Torsten Feig
Vote (1)
Watch (0)

Dates

  • Created:
    Updated: