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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d1df6bc3799debed
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Not intended for use in medical,
Date: 1997/05/17
Message-ID: <EACHUS.97May16200104@spectre.mitre.org>#1/1
X-Deja-AN: 242068048
References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com>
 <dewar.862775250@merv> <5kl9qc$g4d@bcrkh13.bnr.ca>
 <5kmek2$9re@bcrkh13.bnr.ca> <E9rMuy.Hs0@world.std.com> <dewar.863062734@merv>
 <33727FA5.5C7A@sprintmail.com> <dewar.863254456@merv>
 <3374C19F.15FE@sprintmail.com> <dewar.863323812@merv>
 <3376CF85.3E15@sprintmail.com>
Organization: The Mitre Corp., Bedford, MA.
Newsgroups: comp.lang.ada
Date: 1997-05-17T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <3376CF85.3E15@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

  > Well that is nice to know!  I thought I read somewhere that Jean
  > Ichbiah was resistant to some of those changes.

   Jean Ichbiah was concerned about the syntax, not the addition of
the features.  Incidently, Jean was right that his syntax was
"cleaner" or looked better, but Tucker's notation was more useful
because it allowed (eventually) the separation of concepts which are
hopelessly confused in other OO languages.  The vote on the issue
reflected this, was it 2-2 with five abstentions?  (Hmmm.  I think
that the US abstained with the announced intent of changing to the
winning side, so the final was 3-2-4.)  In any case, a close decision
on a very subtle issue.

   Incidently, Tucker did make some changes in response to Jean's
issues, and the final result is probably better than either original
proposal.

  > In other words, tagged types and type derivation are useful tools
  > that have their place, but they are not necessarily the right tool
  > for every problem, and you are not necessarily forced to use them
  > for everything.  Make an informed engineering decision, weigh the
  > trade-offs: If the overhead and dynamic dispatching and the
  > indeterminacy of abstract types are unacceptable to a real-time
  > application, just don't use those features.

   Ah, wonderful.  In the same post I get to explain the confusions
that Ada 95 allows you to sort out.

   Tagged types and type derivation are perfectly useable in contexts
like real-time in Ada 95 with no penalty.  It is only when a call
actually dispatches at run-time when you need to have a concern.  But
if your Ada program has no objects declared to be classwide (i.e.
Bar: Foo'Class;), then no run-time dispatching will occur.

   In Ada 95 an abstract type is one which for which no objects can
be created.  An abstract function is one that can never be called.
An abstract data type can be implemented as a classwide type so you
get run-time dispatching, and you can declare objects to be members of
an abstract class.  But in Bar: Foo'Class; where Foo is an abstract
type, Bar can never be of type Foo, even though it will always have a
type that is derived (directly or indirectly) from Foo.

   Got it?

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...