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=1.7 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_DATE,T_FILL_THIS_FORM_SHORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-01 09:08:42 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!epflnews!dinews.epfl.ch!di.epfl.ch!Magnus.Kempe From: Magnus.Kempe@di.epfl.ch (Magnus Kempe) Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) Date: 1 Oct 1994 12:01:30 GMT Organization: Ecole Polytechnique Federale de Lausanne Distribution: world Message-ID: <1994Oct1.123822@di.epfl.ch> References: <1994Sep27.165203.9192@swlvx2.msd.ray.com> <36bt0c$17oo@watnews1.watson.ibm.com> <1994Sep29.103358@di.epfl.ch> <36eebb$jn5@disunms.epfl.ch> NNTP-Posting-Host: lglsun4.epfl.ch Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: bga.com comp.lang.ada:6360 comp.object:6965 comp.lang.c++:31266 Date: 1994-10-01T12:01:30+00:00 List-Id: adam@irvine.com (Adam Beneschan) writes: : ... the package Company is there "just to get the Ada language to do : what you want", not to represent any concept or abstraction that has : anything to do with the application. This is incorrect. The requirement is for two ADTs which are mutually dependent. Ada 9X offers a hierarchical namespace which allows us to capture the fact that Employee and Office belong together (you're not going to use one without the other), and the root package Company _holds_ that mutual dependency. : As I understand it, inheritance's primary purpose is to model "IS-A" : or "IS-A-KIND-OF" relationships between object types (I believe it's : sometimes used purely for code reuse, although that seems like a : misuse of the concept to me). Here, inheritance doesn't really model : anything--it's just something that got set up in order to get things : to work. You are right that code usually doesn't "model" anything. It's just there to _implement_ a model. You seem to hold that inheritance is good only when it corresponds exactly to an "is-a" relationship of your model. But there are two kinds of inheritance: interface and implementation (or code sharing). The first corresponds to is-A relationships; the second is a means for code sharing. In the particular example you cite, the derivation was not done in the interface but in the private part, so as to _hide_ the inheritance. Compare undue interface inheritance (the client sees the ADT and implementation details, as well as some List stuff which has nothing to do with a Stack ADT) with Lists; package Stacks is type Stack_Type is new Lists.List_Type -- !!! Stack is-a List with private; ... -- Push, Pop, Size ... -- somehow try to hide the operations of List_Type which -- violate the Stack abstraction private type Stack_Type is new List_Type with null record; end Stacks; vs. implementation inheritance (the client does not see anything except the proper ADT) with Lists; package Stacks is type Stack_Type is private; ... -- Push, Pop, Size private type Stack_Type is new Lists.List_Type -- !!! Stack is-implemented-by-a List with null record; end Stacks; There is nothing revolutionary here, and nothing peculiar to Ada. The distinction between interface and implementation inheritance is quite common and useful. One may have a dislike for implementation inheritance, but that's no sufficient reason to forbid its use to those who do find it advantageous. Is it an ugly "workaround"? Maybe, to the extent that someone somewhere will castigate any high-level language mechanism for being a workaround of their favorite assembly language feature. -- Magnus Kempe "I know not what course others may take, but as for me, Magnus.Kempe@di.epfl.ch Give me Liberty... or give me Death!" -- Patrick Henry