Clarifications on the meaning of TMethod/TField, their signatures, and definitions

[tsdh]

It's not really clear to me how TMethod/TField, their signatures, and definitions are supposed to be instantiated. As I understand it, there should be

1. one TMethod/TField per unique method or field name,
2. one TMethodDefinition/TFieldDefinition per, well, definition in a class
3. one TMethodSignature/TFieldSignature per unique string <ReturnType> <MethodName>(<Parameters*>) or <FieldType> <FieldName>.

Example:

class A {int foo(){return 0;}}
class B extends A {int foo() {return -1;}}
class C extends A {int foo() {return 1;}}

So with the rules above, we'd have one TMethod with tName = "foo", one TMethodSignature for int foo(), and three TMethodDefinitions where the ones of B and C override the one of A. Is that how it's supposed to be?

BTW, how are we supposed to handle method declarations, e.g., abstract int foo()?

On a related note: what's the overwritten reference at the TFieldDefinition class meant for? There is no such concept in Java. A field may hide a superclass field but that's still accessible using super.field or ((SuperClass) this).field.

[SvenPeldszus]

It's not really clear to me how TMethod/TField, their signatures, and definitions are supposed to be instantiated. As I understand it, there should be

Yes, that is exactly how it is supposed to be.

BTW, how are we supposed to handle method declarations, e.g., abstract int foo()?

As we excluded i.a. the keyword abstract from our sublanguage of Java declarations like abstract int foo() are not allowed.

On a related note: what's the overwritten reference at the TFieldDefinition class meant for? There is no such concept in Java. A field may hide a superclass field but that's still accessible using super.field or ((SuperClass) this).field. At the point of hiding fields we wanted to stay as general as possible. But you are right the hiding mechanism in Java is not exactly identical to the overriding mechanism for methods.

At this point we tried to keep this reference as general as possible. But you are right there is a small difference between field hiding and method overriding in Java.

Within the overriding class the parent method definitions are still accessible with the keyword super - eg. super.method(). At the casting approach of course method overriding and field hiding are different. While parent methods at this point are really not accessible fields of parents classes are accessible.

As it is still relative early in the challenge and since the final case descriptions are not due Thursday I will rename this reference to avoid further confusion.

However, this is a detail on instruction level, which cannot be changed by an refactoring on the PG. (Introduction of e.g. super to an field call to keep a reference valid is not possible) Accordingly we will not focus on this in the test cases.

[tsdh]

Ok, thanks.