msmiller@aconcagua.src.honeywell.com (Mike Miller) (06/22/91)
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.
chuck@brain.UUCP (Chuck Shotton) (06/22/91)
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
jls@netcom.COM (Jim Showalter) (06/22/91)
>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++. *
jls@netcom.COM (Jim Showalter) (06/23/91)
>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++. *
orville@weyrich.UUCP (Orville R. Weyrich) (06/23/91)
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) -------------------------------------- ******************************
knight@mrco.carleton.ca (Alan Knight) (06/23/91)
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
jls@netcom.COM (Jim Showalter) (06/24/91)
]>>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++. *
philip@pescadero.Stanford.EDU (Philip Machanick) (06/24/91)
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
milt@lax.pe-nelson.com (Milt Ratcliff) (06/24/91)
>]> 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
marc@dumbcat.sf.ca.us (Marco S Hyman) (06/24/91)
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
dugal@neon.Stanford.EDU (Douglas S. Gray) (06/25/91)
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)
spray@convex.com (Rob Spray) (06/25/91)
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."
dugal@neon.Stanford.EDU (Douglas S. Gray) (06/25/91)
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 *
scott@shuksan.UUCP (Scott Moody) (06/25/91)
Related to this top-down vs bottom-up discussion, I just received
the following Unix (sun) fortune:
/usr/games/fortune produced the following output:
Everyting should be built top-down, except the first time.
--
Scott Moody "The Boeing Mountain Network"
scott@shuksan.boeing.com
uunet!bcstec!shuksan!scottjls@netcom.COM (Jim Showalter) (06/26/91)
> 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++. *