Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #16944 > unrolled thread

multiple inheritance

Back to article view | Back to comp.lang.java.programmer

Contents

  multiple inheritance bob smith <bob@coolfone.comze.com> - 2012-08-01 19:28 -0700
    Re: multiple inheritance markspace <-@.> - 2012-08-01 20:07 -0700
      Re: multiple inheritance Gene Wirchenko <genew@ocis.net> - 2012-08-01 21:07 -0700
    Re: multiple inheritance Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-01 23:12 -0400
    Re: multiple inheritance Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-08-01 23:41 -0400
      Re: multiple inheritance Lew <lewbloch@gmail.com> - 2012-08-02 01:05 -0700
      Re: multiple inheritance Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 23:15 -0400
    Re: multiple inheritance Roedy Green <see_website@mindprod.com.invalid> - 2012-08-02 01:10 -0700
      Re: multiple inheritance Arne Vajhøj <arne@vajhoej.dk> - 2012-08-12 23:08 -0400
        Re: multiple inheritance Lew <noone@lewscanon.com> - 2012-08-12 20:19 -0700
          Re: multiple inheritance Arne Vajhøj <arne@vajhoej.dk> - 2012-08-17 22:33 -0400
        Re: multiple inheritance Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-08-13 05:55 -0500
          Re: multiple inheritance markspace <-@.> - 2012-08-13 07:58 -0700
          Re: multiple inheritance Arne Vajhøj <arne@vajhoej.dk> - 2012-08-17 22:38 -0400
    Re: multiple inheritance Jan Burse <janburse@fastmail.fm> - 2012-08-02 10:12 +0200

#16944 — multiple inheritance

Why doesn't Java support multiple inheritance?

[toc] | [next] | [standalone]

#16945

On 8/1/2012 7:28 PM, bob smith wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#16949

On Wed, 01 Aug 2012 20:07:58 -0700, markspace <-@.> wrote:

>On 8/1/2012 7:28 PM, bob smith wrote:
>> Why doesn't Java support multiple inheritance?

>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

[toc] | [prev] | [next] | [standalone]

#16946

On 8/1/2012 10:28 PM, bob smith wrote:
> 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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#16948

On 8/1/2012 10:28 PM, bob smith wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#16952

Joshua Cranmer wrote:
> bob smith wrote:
>> Why doesn't Java support multiple inheritance?

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

[toc] | [prev] | [next] | [standalone]

#17778

On 8/1/2012 11:41 PM, Joshua Cranmer wrote:
> On 8/1/2012 10:28 PM, bob smith wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#16953

On Wed, 1 Aug 2012 19:28:31 -0700 (PDT), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>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)
http://www.youtube.com/watch?v=F-QA2rkpBSY

[toc] | [prev] | [next] | [standalone]

#17777

On 8/2/2012 4:10 AM, Roedy Green wrote:
> On Wed, 1 Aug 2012 19:28:31 -0700 (PDT), bob smith
> <bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
> who said :
>
>> Why doesn't Java support multiple inheritance?
>
> 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

[toc] | [prev] | [next] | [standalone]

#17779

Arne Vajhøj wrote:
> Roedy Green wrote:
>> 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).

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

[toc] | [prev] | [next] | [standalone]

#17978

On 8/12/2012 11:19 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Roedy Green wrote:
>>> 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).
>
> 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

[toc] | [prev] | [next] | [standalone]

#17782

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/2/2012 4:10 AM, Roedy Green wrote:
>>
>> 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).

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

[toc] | [prev] | [next] | [standalone]

#17784

On 8/13/2012 3:55 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/2/2012 4:10 AM, Roedy Green wrote:
>>>
>>> 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).
>
> 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.

[toc] | [prev] | [next] | [standalone]

#17979

On 8/13/2012 6:55 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/2/2012 4:10 AM, Roedy Green wrote:
>>>
>>> 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).
>
> 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

[toc] | [prev] | [next] | [standalone]

#16954

bob smith schrieb:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web