From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: Difference between inheritance and package use Keywords: Inheritance, Object Orientation Message-ID: <1991Jun25.195211.12113@netcom.COM> Date: 25 Jun 91 19:52:11 GMT References: <1991Jun21.224640.24583@src.honeywell.com> <1991Jun24.193341.27161@neon.Stanford.EDU> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: > 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" . 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++. *