comp.lang.ada
 help / color / mirror / Atom feed
From: sdl@MITRE-BEDFORD.ARPA (Litvintchouk)
Subject: Re: Smalltalk-80 as an Ada software environment
Date: Tue, 2-Sep-86 20:38:36 EDT	[thread overview]
Date: Tue Sep  2 20:38:36 1986
Message-ID: <8609030038.AA11234@mitre-bedford.ARPA> (raw)


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

             reply	other threads:[~1986-09-03  0:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1986-09-03  0:38 Litvintchouk [this message]
  -- strict thread matches above, loose matches on Subject: below --
1986-08-28 16:34 Smalltalk-80 as an Ada software environment Jean-Francois Lamy
1986-08-27  1:27 Steven D. Litvintchouk
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox