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 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!nike!ucbcad!ucbvax!MITRE-BEDFORD.ARPA!sdl From: sdl@MITRE-BEDFORD.ARPA (Litvintchouk) Newsgroups: net.lang.ada Subject: re: inheritance in Ada Message-ID: <8608171617.AA08477@mitre-bedford.ARPA> Date: Sun, 17-Aug-86 12:17:19 EDT Article-I.D.: mitre-be.8608171617.AA08477 Posted: Sun Aug 17 12:17:19 1986 Date-Received: Mon, 18-Aug-86 01:02:35 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA List-Id: If I have read the ADA Reference Manual correctly, it seems that ADA(r) does support inheritance of the form used in Smalltalk-80 and other object oriented languages. The inheritance occurs when one declares a new derived type which then inherits all the operations already existing for the type from which it was derived. It's not quite that simple. One problem is what happens to the "instance variables" of the class (type); that is, the "private memory" or internal implementation of each instance of the class. In Smalltalk-80, a subclass inherits everything from its parent superclass, including its instance variables. For example, if there were a class STACK implemented as an array, any subclass of STACK would also inherit that implementation. You could then add additional operations (messages) that manipulate that implementation, as further refinements to the subclass. In Ada, on the other hand, if you define an abstract data type (ADT) in a package specification, you must make its implementation visible, if you want it to be inherited by any type derived from that ADT. (That violates the principle of information hiding, unfortunately.) You cannot make the ADT a private type, because then its implementation is not accessible from any derived type. Ada has this unfortunate conflict between encapsulation (via private types) and full inheritance. Smalltalk doesn't need encapsulation to prevent access to the "private memory" or internal implementation of an object; there simply are no language constructs to directly access an object's private memory; all you can do is send messages to the object that it can decide how to deal with. One thing you could do is create an "inheritance hierarchy" of derived types, all of which had visible implementations, and then create a final set of private types (whose implementations were derived from these inherited types) for use by end-users. But this would require having two types (one private and one visible) for every type in the hierarchy; a clumsy solution at best. Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mitre-bedford UUCP: ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdl