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!mnetor!seismo!topaz!nike!ucbcad!ucbvax!MITRE-BEDFORD.ARPA!sdl From: sdl@MITRE-BEDFORD.ARPA (Litvintchouk) Newsgroups: net.lang.ada Subject: Re: Smalltalk-80 as an Ada software environment Message-ID: <8609030038.AA11234@mitre-bedford.ARPA> Date: Tue, 2-Sep-86 20:38:36 EDT Article-I.D.: mitre-be.8609030038.AA11234 Posted: Tue Sep 2 20:38:36 1986 Date-Received: Wed, 3-Sep-86 02:14:51 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The MITRE Corp., Bedford, MA List-Id: Jean-Francois Lamy writes: > > packages and compilation order semantics). (You would > > build a prototype/model class hierarchy in Smalltalk, and > > after modelling/simulation convinced you it was OK, you would > > then transliterate it to the corresponding Ada equivalent > > for the final product.) > > At first glance this is going to be very hard. Emulating "virtual" > routines (i.e. when a subclass' routines redefines the superclass') is > not elegant not efficient (requires heavy and dirty use of generics). > Ada just isn't a good object-oriented language. My use of the word "transliterate" was a real mistake, because you don't really need it to establish some correspondence between the (Smalltalk) simulation model and the Ada design (see below). As for how hard it is to do inheritance in Ada, I believe that inheritance of classes implemented as types can be simulated using derived types (this has been pointed out on the net already). There are admittedly some problems with this scheme: 1. Encapsulation of Ada: Suppose the parent type is private (so its implementation is hidden in the "private part" of a package spec). Then any type derived from it is likewise "private" in that you can't access its implementation (which you may need to do to add additional methods to the derived type). Fix: make all types in the "class hierarchy" visible. (You can always create new private types whose implementations are derived from types in the class hierarchy.) 2. Dynamic binding of Smalltalk: The class of an object may not be known until runtime, so if you write code that sends a message to some object, you may not know until runtime whether the object can handle it. (This, of course, conflicts with Ada's strong typing.) Unless someone comes up with an effective typing scheme for Smalltalk, the only workaround is to accept less than a total "transliteration" from Smalltalk to Ada. That's OK for my application. I am concerned only with establishing a design in Ada whose "concepts" (classes and associated methods) correspond to those in the object-oriented (Smalltalk) model. Establishing corresponding class hierarchies (classes & associated messages) between the two languages is quite a step forward. I agree with Lamy that Ada is not a good language for object-oriented programming in the Smalltalk/Flavors sense. (Ada has proven a reasonable language for *object-oriented design* in the Abbott/Booch sense, which is significantly different.) 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