Difference between inheritance and package use

Difference between inheritance and package use

[Mike Miller]

This question came up some time ago, but has slipped my mind for one
reason or another since then:

How does (or more properly, how will) the upcoming addition of
inheritance and object oriented stuff (for lack of a better word at
the moment) differ from the definition of something in a package and
its use later?

When I was asked that, I was stumped (I'm not a software guru). Can
anyone enlighten me?

Thanks.

Re: Difference between inheritance and package use

[Jim Showalter]

>How does (or more properly, how will) the upcoming addition of
>inheritance and object oriented stuff (for lack of a better word at
>the moment) differ from the definition of something in a package and
>its use later?

Think of two trees, one built using current Ada mechanisms for
abstraction, such as packages, 'with'ing, and private types,
the other tree built using inheritance.

In the first tree, sub-abstractions are at the leaves, and the
tree is built up from them, layer by layer, using 'with's and
types (probably records) that contain fields of the types of
the lower-level abstractions. In this tree, the most complex
type, and the type created most recently, is at the ROOT,
and the compilation dependency is from the root down to the
leaves.

In the second tree, the root may be a quite simple abstraction,
such as a universal object in the NIH library. More specialized
or complex abstractions are built in a line of descent from the
root to the leaves, with the leaves being the most recently
created abstractions. Note that in this case the compilation
dependency is UP the tree, from the leaves to the root.

Which of these is better? Well, there certainly does seem to
be a lot of argument about it. We know more about the first
kind of tree, because that's how almost all software has been
built traditionally (the information models used in MIS are
this kind of tree, and MIS accounts for 70% of all software [die,
COBOL, die]). On the other hand, there are a growing number of
people who believe strongly that the old way of doing things
is all wrong, that the new kind of tree is far superior, and
they'll chew your leg off at the hip if you give them any static
about it. ;-)

I have been wondering for some time if there isn't some kind of
bifurcation in people's cognitive styles that leads them to favor
one kind of tree over the other. I've had lots of inheritance
evangelists assert that inheritance trees are more "intuitive"
and "natural" and that they more closely model the problem space,
and yet, frankly, if this is true I wonder why so many people have
so gosh darned much trouble USING inheritance to build class libraries
that are actually good for something (I direct you to comp.object
for recent threads containing ample complaining about this very
difficulty). Furthermore, I keep looking around in my own software
projects for areas just screaming out for inheritance, and, while
I do find them, I find a lot MORE cases where the more traditional
tree is a considerably less artificial approach. This is what leads
me to ask (and get a lot of flak for asking) whether the wonders of
inheritance haven't been a wee bit oversold...

For example, I look around in nature and, yes, I do find examples of
inheritance. But I also find tractors. And there are, to the best
of my ability to discern their presence, scant few examples of
inheritance in tractors. What I find in tractors is subassemblies
(big ones, such as chassis, electrical, etc--subsystems), which
in turn are decomposed into smaller components such as differentials,
which are in turn decomposed into yet smaller components such as
wrist pins and gaskets and knobs. And so forth, all the way down
to quarks. And what is true for tractors is true for the human
body, airplanes, telephones, and just about every other physical
object I come into contact with--it is built up from smaller pieces.

Or am I missing something?

P.S. Note that I've said nothing above about genericity, which can
     be a feature of either kind of tree. This is because this
     makes things so complicated I don't want to even try to type
     it all in.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: Difference between inheritance and package use

[Alan Knight]

In article <1991Jun22.013149.28268@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

   <Inheritance vs. Composition stuff deleted>

>Which of these is better? Well, there certainly does seem to
>be a lot of argument about it. We know more about the first

I hardly see that these are contradictory or exclusive.  This is like
having an argument in cooking about which is better, cooking things or
mixing them together.

>people who believe strongly that the old way of doing things
>is all wrong, that the new kind of tree is far superior, and
>they'll chew your leg off at the hip if you give them any static
>about it. ;-)
>
>I have been wondering for some time if there isn't some kind of
>bifurcation in people's cognitive styles that leads them to favor
>one kind of tree over the other. I've had lots of inheritance

Careful, you're starting to use "the world can be divided into two
kinds of people" arguments.  Soon somebody will be claiming that
preference for inheritance or composition will be based on what part
of your brain you use more often.  (It's been done, in BYTE magazine,
no less.  Good for a laugh, anyway). 


>I do find them, I find a lot MORE cases where the more traditional
>tree is a considerably less artificial approach. This is what leads
>me to ask (and get a lot of flak for asking) whether the wonders of
>inheritance haven't been a wee bit oversold...
>
>For example, I look around in nature and, yes, I do find examples of
>inheritance. But I also find tractors. And there are, to the best
>of my ability to discern their presence, scant few examples of
>inheritance in tractors. What I find in tractors is subassemblies
>(big ones, such as chassis, electrical, etc--subsystems), which
>in turn are decomposed into smaller components such as differentials,

  I think that only the most rabid of leg-chewers would argue for the
exclusive use of inheritance over composition.  Inheritance is useful
for describing variations on basic concepts, usually with a lot of
interface sharing.  Composition (i.e. the traditional approach) is
good for describing sub-assemblies.
   A tractor does not share much interface with a wheel or an engine.
Describing a tractor as inheriting from Wheel and Engine, would be
stupid.  A tractor is composed of different pieces.
   A tractor wheel, on the other hand, is not all that different from
an automobile wheel or even a bicycle wheel.  Describing these in
terms of inheritance from a common base class makes good sense.  
   Both hierarchies are useful, and one normally uses both at once.
Tractors are Vehicles, a lot like cars or bicycles.  It is useful to
be able to describe a tractor as being a subclass of vehicle.  All
vehicles share a number of common components (wheels, transmission,
steering mechanism).  Tractors add extra components (baler power
shaft, diesel engine, hydraulics).  Thus a tractor both inherits and
is composed of sub-assemblies.
   All OO languages that I know support both these mechanisms. 
   Undoubtedly there are those (longing to sink their teeth into a
good femur) that have overemphasized the use of inheritance, just as
there are those who attack the need for it at every opportunity.  The
prudent programmer will seek the truth between these opposing views.
-- 
--
  Alan Knight   knight@mrco.carleton.ca  +1 613 788 5783   Support
  Dept. of Mechanical and Aeronautical Engineering         the
  Carleton University, Ottawa, Ontario, Canada, K1S 5B6    LPF

Re: Difference between inheritance and package use

[Jim Showalter]

]>>Which of these is better? Well, there certainly does seem to
]>>be a lot of argument about it. We know more about the first

]>I hardly see that these are contradictory or exclusive.  This is like
]>having an argument in cooking about which is better, cooking things or
]>mixing them together.

Read on. I later point out that arguing over which is
better, inheritance or composition (thanks for the term
"composition", by the way) is as dumb as arguing over
nature vs nurture, or any other black-and-white argument
in a world of grey.

]>Careful, you're starting to use "the world can be divided into two
]>kinds of people" arguments.  Soon somebody will be claiming that
]>preference for inheritance or composition will be based on what part
]>of your brain you use more often.

That would be silly--everybody knows that the real indicator
is not brain usage but, rather, one's astrological sign.

]>   A tractor does not share much interface with a wheel or an engine.
]>Describing a tractor as inheriting from Wheel and Engine, would be
]>stupid.

Agreed, stupid it would be. It would also, by the way, be
a great example of multiple inheritance. ;-)
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: Difference between inheritance and package use

[Milt Ratcliff]

>]>   A tractor does not share much interface with a wheel or an engine.
>]>Describing a tractor as inheriting from Wheel and Engine, would be
>]>stupid.

>Agreed, stupid it would be. It would also, by the way, be
>a great example of multiple inheritance. ;-)

Perhaps, but it would be a very BAD example of multiple inheritance since
a tractor is NEITHER a wheel nor an engine.  A tractor which uses a wheel
or engine would actually be a form of composition.

If the tractor inherits from some 'vehicle' object of which it is a true
specialization the inheritance would be more correct.

I have rarely seen inheritance used without the posibility of also using
composition to provide part of the specialization.

Milt
-- 
Milt Ratcliff                                            milt@pe-nelson.com
PE-Nelson                                                +1.408.725.1107
10040 Bubb Road
Cupertino, CA  95014
-- 
Milt Ratcliff                                            milt@pe-nelson.com
PE-Nelson                                                +1.408.725.1107
10040 Bubb Road
Cupertino, CA  95014

Re: Difference between inheritance and package use

[Philip Machanick]

In article <1991Jun23.135921.19166@cunews.carleton.ca>, knight@mrco.carleton.ca (Alan Knight) writes:
|> Careful, you're starting to use "the world can be divided into two
|> kinds of people" arguments.
Of course the world is divided into two kinds of people. Those
who say the world can be divided into two kinds of people and
those who don't.
-- 
Philip Machanick
philip@pescadero.stanford.edu

Re: Difference between inheritance and package use

[Douglas S. Gray]

In article <1991Jun21.224640.24583@src.honeywell.com> msmiller@aconcagua.src.honeywell.com (Mike Miller) writes:
>
>How does (or more properly, how will) the upcoming addition of
>inheritance and object oriented stuff (for lack of a better word at
>the moment) differ from the definition of something in a package and
>its use later?

   Although there have been a number of good answers covering inheritance 
(notably, Jim Showalter's), I haven't seen one which addressed one very
basic difference between a C++ object and an Ada package.  The object is a
first-class programming construct, where the package is not.  The
encapsulation provided by a package is not as powerful as that in an
object.  You can create an array of objects or pass an object to a
subprogram.  Packages are static where objects are dynamic.

   From what I've read in the Ada 9X reports, it appears that there is no
plan to enhance the power of packages.  Instead, inheritance will be added
to types*.  Does anyone have more complete information than that?

Doug Gray
dgray@sadis02.sa.aflc.af.mil
dugal@cs.stanford.edu

* From Draft Mapping Document (Feb 1991) section 3.4(Derived Types) and
section 7(Ada 9X Packages).  Also, see Draft Mapping Rationale Document
(Feb 1991) section 3(Data Abstraction and Object-Oriented Programming)

Re: Difference between inheritance and package use

[Rob Spray]

In <1991Jun24.193341.27161@neon.Stanford.EDU> dugal@neon.Stanford.EDU (Douglas S. Gray) writes:

>...
>subprogram.  Packages are static where objects are dynamic.

Oh really?  I've seen generic instantiations inside blocks that
were inside loops.  Didn't look very static to me!

--Rob Spray
--spray@convex

"I've seen things you people wouldn't believe.  I saw attack
ships on fire off the shoulder of Orion.  I watched C-beams
glitter in the dark near the Tannhauser Gate.  All these memories
will be lost in time...like tears in rain.  Time to die."

Re: Difference between inheritance and package use

[Douglas S. Gray]

In article <spray.677795942@convex.convex.com> spray@convex.com (Rob Spray) writes:
>In <1991Jun24.193341.27161@neon.Stanford.EDU> dugal@neon.Stanford.EDU (Douglas S. Gray) writes:
>
>>...
>>subprogram.  Packages are static where objects are dynamic.
>
>Oh really?  I've seen generic instantiations inside blocks that
>were inside loops.  Didn't look very static to me!
>
Sorry,  I meant to say ... leaving generics aside.  
-- 
****************************************************************
*   Douglas S Gray                                             *
*   SA-ALC/SC Ada Project Officer                              *
*   DSN:  945-7155               dgray@sadis02.sa.aflc.af.mil  *

Re: Difference between inheritance and package use

[Jim Showalter]

>   Although there have been a number of good answers covering inheritance 
>(notably, Jim Showalter's), I haven't seen one which addressed one very
>basic difference between a C++ object and an Ada package.  The object is a
>first-class programming construct, where the package is not.  The
>encapsulation provided by a package is not as powerful as that in an
>object.  You can create an array of objects or pass an object to a
>subprogram.  Packages are static where objects are dynamic.

You can semi-fake "pure" OO
(should I be calling this "classic" OO instead of "pure"?) in Ada if you use
generic packages as first-class objects, since each instantiation of
such a package does indeed create a separate object, with operations
callable via the "pure" <object>.<method> form. Such packages, typically
with internal state, are cute, but they don't get you all the way there:
they can't be passed as arguments or assigned or stored in arrays, and
they don't inherit.

For example:

generic
    type Item is private;
package Universal_Stack_Class is

    procedure Push (This_Item : in Item);
    function  Pop  return Item;

end Universal_Stack_Class;

package My_Stack is new Universal_Stack_Class (Item => Integer);

My_Stack.Push (7);
Top := My_Stack.Pop;

Note how similar the two above statements are to C++ calls.

Sometimes you have a case where you want to use the above technique without
having even one generic formal--you just need it to be generic to have
the ability to create more than one instance of the package. This is fine.

I do NOT advocate using the above technique. Not only is there the simple
matter of pragmatics--multiple instantiations can be quite costly if you
are using a non-code-sharing (e.g. typical) compiler, and dynamic instantiations
can be REALLY expensive--but there is also the simple fact that a type is
a better object anyway, since it CAN be assigned, etc (more precisely, an
object of some type).

>   From what I've read in the Ada 9X reports, it appears that there is no
>plan to enhance the power of packages.  Instead, inheritance will be added
>to types*.  Does anyone have more complete information than that?

True enough. If you read the Rationale, package types get you sort-of but
not quite really what you want from classes, plus which it would be quite
difficult to migrate a design using the old model to a design using the
new model. I don't have a problem with this decision--whether inheritance
is added to the language via the type model or the module model is not
all that important, so long as it is added. (I realize that the majority
of "pure"/"classic" OO languages use the module route instead of the
type model route, but there are issues with the module route that are
kind of ugly that the type approach does not suffer from--I can elaborate
elsewhere if anybody is interested.)

Despite the above, I would like to see package types added to the language
for OTHER reasons--there are cases where passing a package is the single
best approach to design, and it should be supported, just as it should be
possible to pass procedures and functions. There are some indications in
the draft documents that they plan to support passing procedures and functions
(via, yuck, pointers--is there a C mole in the committee?), and that they
plan to support passing packages as generic actuals. I'd like to see them
all supported, and in the fully general case via function, procedure, and
package types. This would eliminate a lot of assymmetries in the language
definition and a lot of gotchas, although some are not comfortable with
this burring of the distinction between program and data (I think it makes
the language a lot more flexible and dynamic, goals stated in the overview
of the draft documents).
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: Difference between inheritance and package use

[Chuck Shotton]

In article <1991Jun22.013149.28268@netcom.COM>, jls@netcom.COM (Jim Showalter) writes:
> For example, I look around in nature and, yes, I do find examples of
> inheritance. But I also find tractors. And there are, to the best
> of my ability to discern their presence, scant few examples of
> inheritance in tractors. What I find in tractors is subassemblies
> (big ones, such as chassis, electrical, etc--subsystems), which
> in turn are decomposed into smaller components such as differentials,
> which are in turn decomposed into yet smaller components such as
> wrist pins and gaskets and knobs. And so forth, all the way down
> to quarks. And what is true for tractors is true for the human
> body, airplanes, telephones, and just about every other physical
> object I come into contact with--it is built up from smaller pieces.
> 

I think you've actually defined when each "branch" of the tree is utilized
without realizing it. Sure, there are tractors. And they are forms of 4 wheeled,
utilitarian locomotion, which are a sub-class of wheeled transportation and
a peer class to 4 wheeled recreational vehicles. Wheeled transportation is
a form of land vehicle, which is a subclass of vehicles in general.

Looking at the problem this way, it seems that inheritance, etc. is better
suited to decomposing the higher levels of abstraction, while packages, etc.
are better suited (as mentioned in your example above) to implementation details.
Which, amazingly enough, is one of the major features of the package construct
(hiding implementation details). I don't think you'll see a totally object
oriented LARGE system for a long time. Some hybrid of OOP and traditional
decomp., maybe. 

-----------------------------------------------------------------------
Chuck Shotton                 Internet:  cshotton@girch1.med.uth.tmc.edu
                              UUCP:      ...!buster!brain!chuck
"Your silly quote here."      AppleLink: D1683       MacNet: shotton

Re: Difference between inheritance and package use

[Jim Showalter]

>I think you've actually defined when each "branch" of the tree is utilized
>without realizing it. Sure, there are tractors. And they are forms of 4 wheeled,
>utilitarian locomotion, which are a sub-class of wheeled transportation and
>a peer class to 4 wheeled recreational vehicles. Wheeled transportation is
>a form of land vehicle, which is a subclass of vehicles in general.

Indeed. The problem with this is, if I'm trying to build a damned TRACTOR,
why on earth would I want to have to drag around the entire tree of Things
That Move Through Spacetime just to do so? Yes yes yes--I understand the
notion of reuse, but I can reuse pistons and wristpins and all the
subcomponents used to build a tractor (this, last time I looked, was sort
of how most stuff WAS built), so in what way is this better or worse?
If I want to build tractors, I grab a bunch of REUSABLE subcomponents and
put them together to build a tractor. This seems--to my cognitive style,
at least--a far more intuitive way to build a tractor than to try to 
specialize it off of some sort of more general Vehicle_Thing (or, god
forbid, to try to MULTIPLY-inherit it from a Farm_Thing and a Vehicle_Thing).

>Looking at the problem this way, it seems that inheritance, etc. is better
>suited to decomposing the higher levels of abstraction, while packages, etc.
>are better suited (as mentioned in your example above) to implementation details.

I disagree. I do the higher level abstraction in terms of components that
are simply bigger--subsystems. They aren't inherited at all. They're just
more of the same idea--components built up from components, but they're
the largest components in the tree. Like, for example, a DBMS (note that
a DBMS is NOT inherited [yet] from Storage_Thing and Retrieval_Thing and
Query_Thing).

>I don't thinkg you see an example of an object-
>oriented LARGE system for a long time. Some hybrid of OOP and traditional
>decomp., maybe. 

On this, we agree strongly. My point in the original post was NOT that
inheritance trees are useless, or that aggregation trees are the only
way to build software. My point (and if you reread it I think you'll
agree that I made this point) was that both seem to work, they both
have advantages and disadvantages, and that claiming the supremacy
of one over the other makes as much sense as any other black-and-white
argument (e.g. nature vs nurture, punctuated equilibrium vs gradualism,
etc). As Gulliver told the warring factions in his Travels: "Open your
egg from the CONVENIENT end.".
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

Re: Difference between inheritance and package use

[Orville R. Weyrich]

In article <1991Jun23.030631.8027@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>>I think you've actually defined when each "branch" of the tree is utilized
>>without realizing it. Sure, there are tractors. And they are forms of 4 wheeled,
>>utilitarian locomotion, which are a sub-class of wheeled transportation and
>>a peer class to 4 wheeled recreational vehicles. Wheeled transportation is
>>a form of land vehicle, which is a subclass of vehicles in general.
>
>Indeed. The problem with this is, if I'm trying to build a d*mned TRACTOR,
>why on earth would I want to have to drag around the entire tree of Things
>That Move Through Spacetime just to do so? Yes yes yes--I understand the
>notion of reuse, but I can reuse pistons and wristpins and all the
>subcomponents used to build a tractor (this, last time I looked, was sort
>of how most stuff WAS built), so in what way is this better or worse?
>If I want to build tractors, I grab a bunch of REUSABLE subcomponents and
>put them together to build a tractor. This seems--to my cognitive style,
>at least--a far more intuitive way to build a tractor than to try to 
>specialize it off of some sort of more general Vehicle_Thing (or, god
>forbid, to try to MULTIPLY-inherit it from a Farm_Thing and a Vehicle_Thing).

Since I you and I have both seen lots of tractors, I agree that simply 
assembling a tractor out of off-the shelf components makes a lot of intuitive
sense. It is intuitive precisely because we have seen a lot of tractors and
have internalized the general design of that sort of Vehicle_thing.

But suppose that we had never seen a tractor before. In this case our
intuition might fail us, and we might find ourselves groping for analogies
to this [strange] idea of a thing which moves and pulls farm implements the
same way great-grandpa and the old grey mare used to. In this case, inheritance
might be an important part of the cognitive process.

I go on to suggest that you plan to throw the first one away. That is, let your
creative juices flow to create the first prototype tractor using the OO
paradigm. Now that you've got it, you have probably developed enough intuition
for the next step: look to see what the reusable components
seem to be, and design the second model using standard off-the shelf components.
[Your analysis may suggest some new components that you want to add to your
on-the-shelf inventory].

But even still, you might find yourself saying things like: Yeah, I need a 
radiator. But make it's cooling fins a bit larger than the standard size,
because the chaff tends to clog the standard size.

My conclusion: a good designer alternates growing his/her trees in both 
directions. Which mode predominates depends on how well the designer
already understands the problem, on the designer's preferred cognitive
processes, and on the tools and libraries that the designer has available.

>
>On this, we agree strongly. My point in the original post was NOT that
>inheritance trees are useless, or that aggregation trees are the only
>way to build software. My point (and if you reread it I think you'll
>agree that I made this point) was that both seem to work, they both
>have advantages and disadvantages, and that claiming the supremacy
>of one over the other makes as much sense as any other black-and-white
>argument (e.g. nature vs nurture, punctuated equilibrium vs gradualism,
>etc). As Gulliver told the warring factions in his Travels: "Open your
>egg from the CONVENIENT end.".

I like that quote. I'm going to have to re-read my Johnathan Swift.
Please pardon me in advance if I start making any outrageous 'modest'
proposals. :-)

[Dare I go so far as to suggest that engineers prefer to construct
artifacts by agregation of standard sub-components, while scientists
and artists prefer to construct artifacts by inheritance and specialization
of abstract concepts? That would imply that software engineers prefer Ada,
while computer scientists and artsy-fartsy hackers prefer C++.]

Nah -- that is too modest to propose. :-).

--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

Re: Difference between inheritance and package use

[Marco S Hyman]

In article <1991Jun23.030631.8027@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
 > Indeed. The problem with this is, if I'm trying to build a damned TRACTOR,
 > why on earth would I want to have to drag around the entire tree of Things
 > That Move Through Spacetime just to do so? Yes yes yes--I understand the
 > notion of reuse, but I can reuse pistons and wristpins and all the
 > subcomponents used to build a tractor (this, last time I looked, was sort
 > of how most stuff WAS built), so in what way is this better or worse?

You're right.  You don't want to drag around the entire tree ...  I assume (oh
ohh) that you're getting the components for your TRACTOR from a library.
Building a library is hard.  Check out "Designing C++ Libraries" in the USENIX
C++ Conference Proceedings, San Francisco, 1990, by James M. Coggins.  I thing
the points he makes are somewhat language independent.  In particular, that
comprehensive, monolithic class libraries are a bad thing AND that a toolkit
of tiny classes is also a bad thing.

I can read "PACKAGE" for "class."  Something in between is needed.

// marc
-- 
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc