From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 28 Jan 93 23:44:26 GMT
From: alex@cs.umd.edu (Alex Blakemore)
Subject: Re: private types and recompilation
Message-ID: <63819@mimsy.umd.edu>
List-Id: <comp.lang.ada>

erickson@taurus.cs.nps.navy.mil (David Erickson) writes:
> When Ada 83 was designed, why did the designers choose to put
> the details of private types in package specifications, rather than
> in package bodies

The private part info is for use by the compiler which must know how much
storage to reserve for objects of a private type based solely on
information in the spec.  Even if the program cannot know the
representation details, the compiler must.

So if you change the private part, you must recompile clients since
that info has changed.  But you are "guaranteed" that the compilation
will succeed since the client cannot reference the implementation
details.

Rational allows you to change the private parts without invalidating
clients if you use their subsystems.

*** But there is a really nice trick that makes this much less of a
problem. You can define a private type as an access type which
designates an incomplete type to defer defining the representation to
the package body.  That gives the compiler enough info to allocate the
proper amount of storage for objects of the private type.  The only
disadvantage to this is the extra time and complexity of using an
access type.

But you are already using access types anyway.  So you can simply move
the following lines to the package body and then any modifications to
the type LIST do not force recompilations of the specification.

>   type LIST is record
>     A: ATOM;
>     NEXT: POSITION;
>   end record;

You must leave these lines in the private part.
  type LIST;
  type POSITION is access LIST;

-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted