Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!fernwood!dumbcat!marc
From: marc@dumbcat.sf.ca.us (Marco S Hyman)
Newsgroups: comp.object
Subject: Inheritance is a tool (was Re: Readability of Ada)
Message-ID: <294@dumbcat.sf.ca.us>
Date: 28 Apr 91 06:01:30 GMT
References: <jls.672527510@rutabaga> <1991Apr25.170356.21237@odin.diku.dk> <jls.672698352@rutabaga>
Organization: MH Software, Hayward, CA.
Lines: 71

In article <jls.672698352@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
 > Right. Now reread my example: the existing class hierarchy is delivered
 > in BINARY. This is the real world: people want to protect their source.

Jim, as long as all of us are stacking decks to make our viewpoint come out
best let me do another shuffle.  Selecting the proper off-the-shelf package is
part of the _design_ of the program.  Either I buy a binary package that does
do what I want it to do or I make a design decision to wrap the package with
enough code to give the needed function.  Repeat this is a _design_ decision,
not a coding decision.

Now, to your example.  Let's assume that a design decision has been make to
use the package provided in binary form for whatever reasons.  A wrapper needs
to be written.  Simple enough in some languages.  For C++ it might be
something like:

class supershape : public shape {
  private:
    // whatever
  public:
    supershape() {}
    virtual int getRadius() {return 0;}
};

Since using the wrapper and the wrapper interface becomes part of the design
the rest of the code will either use specific leaf classes of shape or the
base class supershape.  Nothing else to modify.  Design issue solved once in
one place.  How would you do it in a language that doesn't support
inheritance?

 > Now, I know from 
 > experience that this is a load of crap...but until the snake oil salesmen
 > stop selling snake oil, I think it's fair to hold them to their claims,
 > don't you?

No.  Holding meaningless people to meaningless claims is a waste of time.
Better is to educate others on how meaningless the claims are so they wont
waste their time either.

 > >Is this some kind of contest, where solutions are required not to
 > >make use of any language features also found in Ada?
 > 
 > Frankly, yes. since I was responding to Bjarne Stroustrup's claim
 > that inheritance was a paradigm not well-supported by Ada, in contrast
 > to C++. So it seems QUITE fair to me to come up with what I consider
 > simple examples of places where C++ support for inheritance degenerates
 > into the exact same solution you'd use in a language that doesn't even
 > claim to HAVE inheritance. Does this seem unfair to you? If so, WHY?

Fair. Unfair.  Don't care.  The world is not fair so I certainly don't expect
people to be...  However, I see this particular slight of hand.  Bjarne points
out a problem that can be solved easily in using inheritance and you counter
with one that can't.  Ok.  I'll agree that inheritance is not a panacea and
that there are classes of problems that C++ and Ada solve equally well -- or
equally bad.  Now you tell me how you would solve the original problem in a
language that doesn't support inheritance.  Subject changes not allowed.

Why are you so down on inheritance?  It's just another programming tool that
can be used for both good an bad.  I don't know how it will scale to very
large projects, do you?

 > --
 > * "Beyond 100,000 lines of code, you should probably be coding in Ada." *
 > *      - P.G. Plauger, Convener and Secretary of the ANSI C Committee   *

I think he's off by an order of magnitude.  100 Kloc is easily (and
successfully) done in C these days.
-- 
// marc
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc