multiple inheritance

[bob smith]

From: bob smith <[email protected]>

Why doesn't Java support multiple inheritance?

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[markspace]

To: bob smith
From: markspace <-@.>

Why doesn't Java support multiple inheritance?

The diamond problem. I'm not really up on the details however.

I can tell you from hanging out on the lambda-dev list (Java 8 features) that
Brian Goetz has pushed back strongly on any sort of multiple inheritance.
Apparently the diamond problem is a real bear and introduces real complexity
into both the compiler and the user code that can cause big problems in the
long run.

http://en.wikipedia.org/wiki/Diamond_problem

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Eric Sosman]

To: bob smith
From: Eric Sosman <[email protected]>

Why doesn't Java support multiple inheritance?

To discourage formation of a Kennefeller dynasty?

Because diamonds are a girl's best friend but a programmer's
biggest headache?

The web is full of pages discussing the pros and cons of
Java's choice. Perhaps you should read a few of them and then (if so moved)
post "Excuse E for omitting multiple inheritance seems unconvincing to me for
reasons R1 and R2, despite supporting arguments S1 through S9. Here's a
concrete example where I think R1 and R2 trump S* and overturn E; what do
others think?"

--
Eric Sosman
(e-mail address removed)

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Joshua Cranmer]

To: bob smith
From: Joshua Cranmer <[email protected]>

Why doesn't Java support multiple inheritance?

Because multiple inheritance is really, really, really complicated and
confusing for most users.

The short answer is the diamond problem:

class A { int varA; };
class B : A { int varB; };
class C : A { int varC; };
class D : B, C { int varD; };

There are two main points of contention in this kind of hierarchy: 1. How many
copies of varA should D have? Intuitively, one is probably what most people
would expect, but the implementations of B and C would have to cooperate in
realizing that their superclass may be shared with D. It also incurs a penalty
in runtime costs 2. How does initialization/override order get resolved? Is it
"BFS"-y (like D, B, C, A) or "DFS"-y (D, B, A, C)? There are even more
convoluted orders in practice (C3 appears to be the most common nowadays), but
this is the sort of stuff that tends to cause nasty sorts of little edge cases
in practice.

It is rare in practice that you need true multiple inheritance, in the sense of
inheritance of implementation; multiple inheritance of interface is common, and
this is as far as Java goes.

--
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald E. Knuth

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Gene Wirchenko]

To: markspace
From: Gene Wirchenko <[email protected]>

The diamond problem. I'm not really up on the details however.

Such a lovely name. The link does go into enough detail to
understand it.

I can tell you from hanging out on the lambda-dev list (Java 8 features)
that Brian Goetz has pushed back strongly on any sort of multiple
inheritance. Apparently the diamond problem is a real bear and
introduces real complexity into both the compiler and the user code that
can cause big problems in the long run.

http://en.wikipedia.org/wiki/Diamond_problem

It also has a number of different handlings in MI languages so
there is not an obvious solution.

Sincerely,

Gene Wirchenko

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Roedy Green]

To: bob smith
From: Roedy Green <[email protected]>

Why doesn't Java support multiple inheritance?

1. It has interfaces which gives much of the ability at lighter weight..

2. Java originally was intended for set top boxes. That is too heavyweight a
feature.

3. Study Eiffel. implementing it is quite tricky, especially when you get name
clashes.

you might see it in Java 11 or so, or whatever language inherits the Java
mantle.
..
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the
exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Lew]

To: Joshua Cranmer
From: Lew <[email protected]>


Strictly speaking, Java does support multiple inheritance, just not from
classes.

This is because multiple inheritance of implementation is silly.

Because multiple inheritance is really, really, really complicated and
confusing for most users.

The short answer is the diamond problem:

class A { int varA; };

class B : A { int varB; };

class C : A { int varC; };

class D : B, C { int varD; };

There are two main points of contention in this kind of hierarchy:

1. How many copies of varA should D have? Intuitively, one is probably

what most people would expect, but the implementations of B and C would

have to cooperate in realizing that their superclass may be shared with

D. It also incurs a penalty in runtime costs

2. How does initialization/override order get resolved? Is it "BFS"-y

(like D, B, C, A) or "DFS"-y (D, B, A, C)? There are even more
convoluted orders in practice (C3 appears to be the most common
nowadays), but this is the sort of stuff that tends to cause nasty sorts
of little edge cases in practice.

It is rare in practice that you need true multiple inheritance, in the
sense of inheritance of implementation; multiple inheritance of
interface is common, and this is as far as Java goes.

Quite so.

--
Lew

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Jan Burse]

To: bob smith
From: Jan Burse <[email protected]>

Why doesn't Java support multiple inheritance?

Java only doesn't allow multiple implementation inheritance. But it does allow
multiple signature inheritance via interfaces.

So you can have where P and Q are interfaces:

class A implements P;

class B implements Q;

class C implements P, Q;

If you want also implementation inheritance, you can use Scala, which does some
rewriting to Java for you via delegates or other approaches.

Bye

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: Roedy Green
From: Arne Vajhoj <[email protected]>

1. It has interfaces which gives much of the ability at lighter
weight..

Only for a very limited type of types (those with no implementation at all).

2. Java originally was intended for set top boxes. That is too
heavyweight a feature.

C++ is used a lot in embedded context, so that argument does not hold water.

3. Study Eiffel. implementing it is quite tricky, especially when you
get name clashes.

you might see it in Java 11 or so, or whatever language inherits the
Java mantle.

Not likely.

It is not desirable.

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: Joshua Cranmer
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <[email protected]>

Because multiple inheritance is really, really, really complicated and
confusing for most users.

The short answer is the diamond problem:

class A { int varA; };
class B : A { int varB; };
class C : A { int varC; };
class D : B, C { int varD; };

There are two main points of contention in this kind of hierarchy:
1. How many copies of varA should D have? Intuitively, one is probably
what most people would expect, but the implementations of B and C would
have to cooperate in realizing that their superclass may be shared with
D. It also incurs a penalty in runtime costs
2. How does initialization/override order get resolved? Is it "BFS"-y
(like D, B, C, A) or "DFS"-y (D, B, A, C)? There are even more
convoluted orders in practice (C3 appears to be the most common
nowadays), but this is the sort of stuff that tends to cause nasty sorts
of little edge cases in practice.

It is rare in practice that you need true multiple inheritance, in the
sense of inheritance of implementation; multiple inheritance of
interface is common, and this is as far as Java goes.

It should be noted that Scala with its trait has come up with a solution that
allows pulling in multiple traits with implementation code without the diamond
problem.

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Lew]

To: Arne Vajhøj
From: Lew <[email protected]>

Only for a very limited type of types (those with no implementation
at all).

That is true, but "very limited" might be misconstrued as "not very useful".
That Java limits multiple inheritance to interfaces is a design decision of the
language, and confers advantages. These advantages come to the fore when one
follows various recommended practices such as those found in Joshua Bloch's
/Effective Java/.

There are vanishingly few cases where one cannot mix in implementation through
a combination of composition and single inheritance of implementation ('class'
parent types) to accomplish with equal facility what multiple implementation
inheritance would. Avoiding the sorts of downsides mentioned upthread is the
motivation.

There are many times one wishes to guarantee the presence of a contractual
method that is required by several interfaces. 'java.lang.Runnable' need not be
the only interface to specify 'void run();'. Let's say you have a custom
'Raceable' interface that also specifies 'void run();'. There's every reason
to let an algorithm that expects a 'Raceable' to use some concrete type's
'run()' even if it also serves to keep 'Runnable''s promise. Multiple
inheritance of promises is easier to understand and keep bug free.

This ties into a programming approach I call "type-based programming". Given
some concrete type

public class FormulaOne implements Runnable, Raceable
{
@Override
public void run() { ... }
}

client code can freely say:

FormulaOne fone = new FormulaOne();
Raceable raceable = fone;
Runnable runnable = fone;

and so forth. Only signatures are shared, so implementation won't be confused.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Leif Roar Moldskred]

To: Arne Vajhøj
From: Leif Roar Moldskred <[email protected]>

Only for a very limited type of types (those with no implementation
at all).

At times, I've wished that Java had automatic delegation (composition) in
addition to inheritance and interface implementation, where the compiler
automatically adds the public methods and fields from delegated objects, except
when there's a conflict of names. Something like this, maybe:


public class ClassAlfa {
public void alfaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}

public class ClassBeta {
public void betaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}


public class Delegator {
private delegate ClassAlfa ALFA;
private delegate ClassBeta BETA;

public void sharedMethod( ) {
ALFA.sharedMethod( );
}

public void anotherSharedMethod( ) {
ALFA.sharedMethod( );
BETA.sharedMethod( );
}
}

public class Example {
public static void main( String[] args ) {
private Delegator delegator;

delegator.alfaMethod( );
delegator.betaMethod( );
delegator.sharedMethod( );
delegator.anotherSharedMethod( );
}
}

--
Leif Roar Moldskred

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[markspace]

To: Leif Roar Moldskred
From: markspace <-@.>

At times, I've wished that Java had automatic delegation (composition)

"Automatic delegation" is what I want. I've even invented my own little syntax
for it:

public SomeClass extends Fubar implements List(myList), OtherThing {

private AbstractList myList = new ArrayList();

....

}


where the parenthesis in the interface list is a forward declaration to a field
that will be the delegate for that particular interface. It really shouldn't
be that hard to do, just a few synthetic methods.

I really rather upset that we aren't getting something like this with Java 8.
I don't see any reason not to fix this right now, honestly.

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <[email protected]>

That is true, but "very limited" might be misconstrued as "not very
useful". That Java limits multiple inheritance to interfaces is a design
decision of the language, and confers advantages.

Indeed.

Implementation inheritance is not in fashion in Java, so interfaces is the
majority of cases.

A classic text:

http://www.artima.com/intv/gosling34.html

There are vanishingly few cases where one cannot mix in implementation
through a combination of composition and single inheritance of
implementation ('class' parent types) to accomplish with equal facility
what multiple implementation inheritance would. Avoiding the sorts of
downsides mentioned upthread is the motivation.

There are some solutions to those problems. But Java was designed to be simple,
so we got what we got.

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

 

[Arne Vajhøj]

To: Leif Roar Moldskred
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <[email protected]>

Only for a very limited type of types (those with no implementation
at all).

At times, I've wished that Java had automatic delegation (composition)
in addition to inheritance and interface implementation, where the
compiler automatically adds the public methods and fields from
delegated objects, except when there's a conflict of names. Something
like this, maybe:


public class ClassAlfa {
public void alfaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}

public class ClassBeta {
public void betaMethod( ) { ... }
public void sharedMethod( ) { ... }
public void anotherSharedMethod( ) { ... }
}


public class Delegator {
private delegate ClassAlfa ALFA;
private delegate ClassBeta BETA;

public void sharedMethod( ) {
ALFA.sharedMethod( );
}

public void anotherSharedMethod( ) {
ALFA.sharedMethod( );
BETA.sharedMethod( );
}
}

public class Example {
public static void main( String[] args ) {
private Delegator delegator;

delegator.alfaMethod( );
delegator.betaMethod( );
delegator.sharedMethod( );
delegator.anotherSharedMethod( );
}
}

You IDE should be able to generate the code for you.

But it could save some code in some cases.

Arne

--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24