Re: Interface/Implementation (was Re: Design by Contract)

["John G. Volan" <johnv@ac3i.dseg.ti.com>]

Matthew Heaney wrote:
> 
> In article <EFyrH2.7z2@syd.csa.com.au>, nospam@thanks.com.au wrote:
> 
> >IMO, there's no excuse for imposing dependency-related ordering
> >in an age of multi-pass compilation.
> 
> Note that many computer scientists, among them Tony Hoare, believe that a
> measurement of goodness of a language is its ability to be compiled using a
> single pass.  In that tradition, Ada was design so that it could be
> compiled in a single pass.

There is a whole other dimension to the ordering of source code in Ada
which has not been mentioned: elaboration order.  

For those of you on this thread not familiar with Ada's elaboration
model, here's the gist:  Every declaration in an Ada program gets
"elaborated" at a specific point in time during execution. "Elaboration"
is the process whereby a given declaration "takes effect" at run time. 
What this means depends on what kind of declaration we're talking
about.  For instance, if it's an object declaration, then "taking
effect" means that the object is allocated memory (on the heap or on the
stack or in a register as the case may be) and any implicit or explicit
initialization of its contents occurs.

Elaboration is linear: Declarations are elaborated in the order in which
they appear in the source text. So the order in which you declare things
can potentially have an effect during execution.

Since Ada verifies at compilation time that you haven't referred to
anything before it's been declared, this also guarantees (more or less)
that the thing will have been elaborated and actually exist at run time,
before you can execute any statements that reference it.  This can be a
very useful property.

For instance, consider the problem of classwide global data ("static
members", in C++ parlance).  When do these beasts get initialized?  In
Ada, you'd just have some "global" variables/constants declared in the
body of a package, but outside of any procedure or type declaration in
that package.  The variables/constants would get elaborated (in the
order they appear) at the time that their enclosing package gets
elaborated.  When is that? Well, according to the rules, a package gets
elaborated (more or less) sometime before any of its clients (any units
that "with" the package).  So you're guaranteed (more or less) that
those globals are initialized before any client can call any of the
subprograms from that package.

(I said "more or less" in the paragraphs above because there are some
subtleties to Ada's elaboration model, but we don't really need to go
into them right now.)

Eiffel doesn't care about the order in which things are declared, but it
also lacks this notion of elaboration order.  So how does it handle
intializing classwide globals?  I seem to recall something about "once"
methods -- routines that get executed just once, the first time they are
called.  The results are cached, and all subsequent calls just return
the cached results.  Supposedly you can initialize classwide globals
inside such methods.  Do I have that right?  If so, it seems to me that
Ada's idiom for this is more straighforward than Eiffel's.  (I'm not
saying it's better, just more straightforward for this particular
application.)

-- 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Raytheon/TI Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using " & 
                 "them would be totally erroneous...or is that just "  &
                 "nondeterministic behavior now? :-) ");
------------------------------------------------------------------------