Closed tsdh closed 9 years ago
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.
Ok, thanks.
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 beTMethod
/TField
per unique method or field name,TMethodDefinition
/TFieldDefinition
per, well, definition in a classTMethodSignature
/TFieldSignature
per unique string<ReturnType> <MethodName>(<Parameters*>)
or<FieldType> <FieldName>
.Example:
So with the rules above, we'd have one
TMethod
withtName = "foo"
, oneTMethodSignature
forint foo()
, and threeTMethodDefinitions
where the ones ofB
andC
override the one ofA
. 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 theTFieldDefinition
class meant for? There is no such concept in Java. A field may hide a superclass field but that's still accessible usingsuper.field
or((SuperClass) this).field
.