Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!godot.cc.duq.edu!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!vixen.cso.uiuc.edu!sdd.hp.com!bone.think.com!blanket.mitre.org!sed.psrw.com!psinntp	!psinntp!psinntp!psinntp!commpost!usenet
From: pardoej@lonnds.ml.com (Julian Pardoe LADS LDN X1428)
Subject: Re: Will Java kill C++?
Message-ID: <Dr1G7K.GJs@tigadmin.ml.com>
Sender: usenet@tigadmin.ml.com (News Account)
Reply-To: pardoej@lonnds.ml.com
Organization: Merrill Lynch Europe
References: <4mark8$e5a@gaia.ns.utk.edu>
Date: Tue, 7 May 1996 13:59:43 GMT
Lines: 72
Xref: glinda.oz.cs.cmu.edu comp.lang.java:48139 comp.lang.c++:188748 comp.lang.smalltalk:38469

In article <4mark8$e5a@gaia.ns.utk.edu>, mbk@caffeine.engr.utk.edu (Matt Kennel) writes:
-->Julian Pardoe LADS LDN X1428 (pardoej@lonnds.ml.com) wrote:
-->: However given that C++ uses inheritance to express interface conformance, MI is
-->: necessary and reasonable.  There's nothing unsound about the idea that an object
-->: might need to conform to more than one interface.
-->
-->: Given all this, it seems to me that the Java approach of allowing single inheritance
-->: (for implementation) plus the ability to conform to multiple interfaces is the
-->: correct way to go.
-->
-->And why is there anything unsound about the idea that an object might want
-->to create its implementation from more than one pre-existing class?
-->
-->(no, I don't like C++'s model but existing practice shows how to do both
--> kinds of MI simultaneously, and do them well.)

Well, I haven't thought my way through all this yet and I was trying to
defend MI rather than attack it.  (It was only a few years ago that the
luddite ``MI is unnecessary'' view was widely held and the comment I was
responding too was basically ``MI?  Just say no!''.)  However, I do have
doubts about multiple inheritance of implementation.  It seems clear to me
that C++'s virtual inheritance is a stinky hack.  We have to write:

    class A {...};
    class B : public virtual A {...};
    class C : public virtual A {...};
    class D : public B, public C {...};

when (it seems to me) the virtualness of A as a base is something that classes
B and C should not have to know about.  Why should class B have to know that
is going to be used as a base class of some class that will inherit an A via
some other route?  This is surely class D's business (or maybe class A -- if
A is some class like Object then it's at that level that it will be known that
sharing is required). 

So I don't think that virtual bases count as ``doing it well''!!

What does it mean if B declares A virtual and C doesn't?  I guess the A is
not shared since while B is happy to share C isn't (or is it C that is happy
to share or not while B insists on sharing?).  Add more classes and we can
get situations where B1 will share with B2 but won't share with C1 or C2.

Basically, when I think about this question I end up confused and wonder if
this is because I'm trying to make sense of something that is fundamentally
non-sensical.  I haven't worked it out yet!

This plus general doubts whether inheritance of implementation is more than
a convenience lead me to my current (non-final) position.  I can't quite
dismiss inheritance of implementation and say that people should delegate to
a member object because of once key difference: a base object is in some sense
_the_same_object_ as its derivee whereas an included object isn't the same object
as its includer, i.e. given
    class A {...};
    class B : private A {...};
    class C { private: A m_a; ... };

    B b; C c;

The A in b is the same object as b itself whereas c.m_a is not the same object
as c (and this regardless of the fact of whether or not (void *)(A *)&b ==
(void *)&b or (void *)&c == (void *)&c.m_a).  (Pointers are not a surrogate
for object identity in C++!!)

-- jP --

PS: For what it's worth (and if he's following this thread he might like to
comment) I once heard Bjarne Stroustrup say words to the effect that he had
considered private inheritance [i.e. inheritance of implementation alone] as
of no use but that Andrew Koenig had come up with some unusual cases in library
design where it proved useful.


