sdl@linus.UUCP (Steven D. Litvintchouk) (08/27/86)
We at MITRE Corp. have been looking into using the Smalltalk-80
programming environment as a software engineering environment to
support the development of real-time software systems to be
implemented in the Ada programming language. (We in the U.S.
aerospace industry must deliver software in Ada, not Smalltalk.) But
Smalltalk-80 provides a wonderfully user-extensible environment that
can do such things as:
1. windowing, word processing, other mundane things (Question: can
any Smalltalk-80 system, such as PS on Sun workstations, invoke tools
from the host operating system like Ada compilers?)
2. Simulation/modelling/rapid prototyping of software systems that
are ultimately to be implemented in Ada
3. Software reusability, by taking a Smalltalk class hierarchy and
constructing its Ada equivalent (using Ada
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.)
4. Research into Ada software performance. The Ada programming
language includes facilities for multitasking, interrupt handling,
dynamic storage allocation/deallocation, etc. Every Ada compiler
comes with a runtime library capable of doing such things. We would
like to create a behavioral model (in Smalltalk) of a hypothetical,
generalized, instrumented, Ada runtime library, in order to learn
about the state of the art in runtime support for Ada multitasking and
storage management.
I plan to be at OOPSLA '86. If anyone out there is also interested in
such "real-world" software engineering applications of Smalltalk,
please let me know; perhaps we could get together at OOPSLA and
compare notes. Thanx very much in advance!!!
Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA 01730
Fone: (617)271-7753
ARPA: sdl@mitre-bedford
UUCP: ...{cbosgd,decvax,genrad,ll-xn,philabs,security,utzoo}!linus!sdllamy@utai.UUCP (Jean-Francois Lamy) (08/28/86)
In article <254@linus.UUCP> sdl@linus.UUCP (Steven D. Litvintchouk) writes: >3. Software reusability, by taking a Smalltalk class hierarchy and > constructing its Ada equivalent (using Ada > 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. Jean-Francois Lamy AI Group, Dept of Computer Science CSNet: lamy@ai.toronto.edu University of Toronto EAN: lamy@ai.toronto.cdn Toronto, ON, Canada M5S 1A4 UUCP: lamy@utai.uucp -- Jean-Francois Lamy AI Group, Dept of Computer Science CSNet: lamy@ai.toronto.edu University of Toronto EAN: lamy@ai.toronto.cdn Toronto, ON, Canada M5S 1A4 UUCP: lamy@utai.uucp
sdl@MITRE-BEDFORD.ARPA (Litvintchouk) (09/03/86)
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