Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.ada
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!psinntp!psinntp!psinntp!psinntp!merlin.hgc.edu!jcm
From: jcm@hgc.edu (James McKim)
Subject: Re: Has C++ had its day?
Message-ID: <1995Jun30.142220.4193@merlin.hgc.edu>
Sender: usenet@merlin.hgc.edu (Action News Central)
Organization: The Hartford Graduate Center
References: <NEWTNews.804269222.4596.sellers@hgc.edu> <NEWTNews.804415994.23097.sellers@sellers.sellers.com>
Date: Fri, 30 Jun 1995 14:22:20 GMT
Lines: 142
Xref: glinda.oz.cs.cmu.edu comp.object:34039 comp.lang.smalltalk:25267 comp.lang.ada:31950

In article <NEWTNews.804415994.23097.sellers@sellers.sellers.com> John Sellers <sellers@sellers.com> writes:
>
>In Article<1995Jun28.140600.6412@merlin.hgc.edu>, <jcm@hgc.edu> 
>write:
>> ...
>> >However, multiple inheritance can easily become a real rat's 
>> >nest.  It is an open invitation to making things over complex.
>> 
>> Well, I agree it can easily be misused, but so can nearly every 
>
>> feature in any language. ...
>
>Slow down there.  MI is more dangerous than you give it credit 

Is it? How much have you used MI? I use inheritance for subtyping
almost exclusively and fine that MI comes up quite naturally in
virtually every application. As you might guess from my .sig I use
Eiffel, which has very clear and straightforward semantics for
dealing with the issues that MI presents. I rarely have difficulty.

>for.  MI is to OOP as goto is to structured programming.  You 

It can be misused in a way similar to the way goto was misused. The 
solution to the goto problem was not to implement an artificial
rule on the number of goto's in the program. Instead, people imposed
a discipline on the way they used goto (branching, loops, procedure calls).
Later, languages were designed that enforced this discipline. I am
trying to understand what discipline is enforced by limiting a language
to single inheritance.
 
>don't ever what to use MI without some careful OOP think anymore 
>than you would ever use goto without careful structured 

I agree.

>programming think.  Put even a little more stronger:  Your MI 
>tree had better be well thought out or the chances are 99% you 
>will end up in a mess.  With single inheritance you can 
>occasionally get away with being a little informal about your 
>approach, with MI you try that and sooner or later you are going 
>to pay a price.

Perhaps. I suspect our experiences with MI are vastly different.

>
>> ...
>> >Sticking with single inheritance makes it easier to structure 
>> >class so that each class has one main purpose in life.
>> 
>> Perhaps. If true, wouldn't disallowing inheritance make it even 
>easier?
>
>Sure you can disallow inheritance, but don't call it OOP if you 
>do.

Well, some people won't call it OOP if you disallow MI, but so what?
I note that you didn't answer my question.

>
>> ... A number of recent
>> Smalltalk posters have indicated that they don't use it to 
>model
>> is-a-kind-of (i.e. subtyping) relationships. 
>> ...
>> So I'm wondering just
>> what you _do_ use it [inheritance] for. 
>
>I do, but I like to think of it as specialization, because I like 
>the connotations better.  Its not much problem to branch off in 

Fine, I agree that specialization has slightly different connotations
than subtyping (although I'm not sure we'd agree on what those differences
are :-)). This strikes me as a reasonable discipline to enforce when
deciding whether to use inheritance or not. So what are these terrible
problems that arise if you enforce the same discipline in the use
of multiple inheritance?

>another direction by adding instance variables for an instance 
>from some other part of the hierarchy in order to get some of the 
>effects of MI.  Also now holders, adaptors, and wrappers are 
>being used a lot more than they used to.  That can be a nice way 
>to move off in another direction and still maintain a uniform 
>protocol.

Yes, of course you can simulate MI. That is not the issue.

>
>The flavor of doing things this way is you don't lose that sense 
>of a single unifying force in the current hierarchy which seem to 
>be a major characteristic of many of the better inheritance 
>hierarchies as viewed from various abstract classes within the 
>hierarchy.  In Visual Works, VisualComponent is an excellent 
>example.  ALL VisualComponents have certain nice display 
>characteristics, and ALL Views, which happen to be in the 
>VisualComponent subHierarchy, have certain other characteristics.
> If you want to get the flavor of a very nice parsing of 
>incrementally adding characteristics using inheritance, look 
>closely at the VisualComponent hierarchy in VW.

If I understand correctly, Views inherit from  VisualComponent and
add extra features. That is, the descendants don't hide any
ancestors' features ot subvert their meanings. If so, this sounds 
like subtyping to me.


[..]

>
>> ...
>> What relationship, say between class A and class B, is it that 
>single 
>> inheritance handles well? And is there never a case where A 
>might
>> have this relationship to another class, C, as well?
>> 
>> ...
>
>When you talk about relationships, I don't think that has much to 
>do with inheritance.  This sounds more like "Part of" or "Object 
>Connection".  You could have an instance variable called B_or_C, 
>or perhaps better yet, BHolder_or_CHolder, where the holders 
>share a common protocol and the holders act as adaptors for B and 
>C.  

Well, unless I've misinterpreted the above, it seems that you use
inheritance for subtyping (an is-a-kind-of relationship. OTOH if 
I'm wrong and you truly can't verbalize
when it's appropriate to use inheritance, then I can certainly understand
how you would have difficulty benefiting from multiple inheritance.


[..]

Interesting discussion,
-- Jim


-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook 
Internet:  jcm@hgc.edu        Subscribe early and often!
