| Multiple inheritance in OT/J [message #569349] |
Mon, 01 March 2010 15:12  |
 Eugene Hutorny
Messages: 110
Registered: January 2010 |
Senior Member |
|
|
While reading Kasper's thesis I discovered that OT/J supports dual inheritance.
I've reread http://www.objectteams.org/def/1.3/s1.html#s1.3 again and found only one statement that may imply dual inheritance http://www.objectteams.org/def/1.3/s1.html#s1.3.2:
OTJLD
> In addition to implicit inheritance, roles may also inherit using the standard Java keyword extends.
which, from the first reading, I actually (mis)understood as "both implicit and explicit inheritance available but only one can be used".
I've made some experiments to see how you have solved the diamond problem, please clarify if my findings are correct:
1.OT/J uses 'copy inheritance', which, in regards to the diamond problem, is equivalent to virtual inheritance in C++.
2.Methods from both tsuper and super are merged into this class
3.Method names resolved in the following order: this, tsuper, super
4.Constructors are resolved in the following order: this, super
Also, there were some unclear situations.
public team class AT {
public class A {
public A(String aname) {
name = name + aname;
}
public String name = "";
// ...
}
public class B extends A {
public B() {
super("AT.B");
}
// ...
}
public class C extends A {
/* public C() { // default constructor is commented out
super("AT.C");
} */
public C(String aname) {
super(aname);
}
// ...
}
}
public team class BT extends AT {
public class B { // ??1 Role inherits incompatible 'extends' declarations: AT.B is not a sub-type of BT.A (OTJLD 1.3.2(b)).
public B() { // ??2 Implicit super constructor BT.A() is undefined for default constructor. Must define an explicit constructor
tsuper();
}
}
public class C extends B {
public C() { // ??3 AT.C has no default constructor, but compiler does not complain
super();
//tsuper("BT.C"); // ??4 Constructor call (tsuper) must be inside a role constructor (OTJLD 2.4.2).
}
}
}
??1. I had to define role B in team BT. Not clear why it is needed and why role A is not needed in BT.
??2. Documentation says: Unlike regular inheritance, constructors are also inherited along implicit inheritance, and can be overridden just like normal methods. . The compiler complained about missing constructor BT.B();
??3. AT.C has no default constructor, but compiler did not complain and allowed to create an unitialized instance
??4. There is no way to call tsuper constructor in BT.C
Sources for this test are available http://hutorny.in.ua/wp-content/uploads/2010/03/exer22.zip
|
|
|
| Re: Multiple inheritance in OT/J [message #569372 is a reply to message #569349] |
Tue, 02 March 2010 13:16  |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi Eugene,
I admire your example, which trumps our not-so-small test suite.
I have extracted tests and bugs for two problems, see
https://bugs.eclipse.org/304344
https://bugs.eclipse.org/304346
Your issue ??4 is actually blurred by a wrong compiler message.
The correct message should read:
Constructor call (tsuper) must be the first statement in a role constructor (OTJLD 2.4.2)
This leads me to what I see as a misunderstanding behind ??3 and ??4:
We could not forge Java to the degree that a method can contain two
super constructor calls. §2.4.2(a) defines:
Each constructor of a role that is not bound to a base class must use one of this(..), super(..) or tsuper(..).
It should perhaps be stronger by saying "must use exactly one of ...".
Regarding your example this means:
??3: The compiler is correct not to flag this, because the current ctor
overrides the tsuper version and *instead* only calls the explicit super().
Initialization wrt type C is the responsibility of the body of this ctor.
??4: You correctly describe that the tsuper ctor cannot be invoked. This is
correct because that ctor would call the super-ctor from A which would
be wrong in the context of BTeam.C.
More answers:
Quote:
> 1.OT/J uses 'copy inheritance', which, in regards to the diamond problem, is equivalent to virtual inheritance in C++.
It is equivalent in so far, as indeed no separate versions of a method are
created if it is inherited through several inheritances lines (given a common
root of those lines of inheritance).
Quote:
> 4.Constructors are resolved in the following order: this, super
I'm not sure in which situation you'd see constructor *lookup* along the super
chain. By contrast, wrt to regular inheritance ctors are (still) statically bound.
Only implicit inheritance supports dynamic binding of constructors.
Given:
team class ATeam {
public class R0 {}
public class R1 extends R0 {}
}
team class BTeam extends ATeam { }
R1 createR1(final ATeam t) {
return new R1<@t>();
}
The allocation expression statically binds to a constructor "R1()",
it can never directly invoke a "R0()" ctor. However, the selection
between ATeam.R1 and BTeam.R1 happens at runtime depending
on the dynamic type of t.
Underlying these rules is the intuition that roles ATeam.R1 and
BTeam.R1 are almost the same, they share the same simple name "R1",
clients cannot see which version is called, tsuper dispatch has
precedence over super etc.
Does this help to clarify?
Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.01796 seconds
] 
Search
Help
Register
Login
Home
