Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Multiple inheritance in OT/J
Multiple inheritance in OT/J [message #569349] Mon, 01 March 2010 15:12 Go to next message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
While reading Kasper's thesis I discovered that OT/J supports dual inheritance.
I've reread again and found only one statement that may imply dual inheritance
> 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() {
// ...
public class C extends A {
/* public C() { // default constructor is commented out
} */
public C(String 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
public class C extends B {
public C() { // ??3 AT.C has no default constructor, but compiler does not complain
//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
Re: Multiple inheritance in OT/J [message #569372 is a reply to message #569349] Tue, 02 March 2010 13:16 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1843
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

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:
> 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).

> 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.

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?
Previous Topic:runtime workbench problem
Next Topic:What makes a class a role?
Goto Forum:

Current Time: Sun Jan 16 11:06:20 GMT 2022

Powered by FUDForum. Page generated in 0.01992 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top