At 05:35 PM 4/14/98 -0700, AdaWorks wrote:
> If the context clause is
>specific to the implementation of a subunit, why would it be
>coded for the entire package body?  If the goal is to reduce
>dependencies, then only the subunit needs to be re-compiled when
>the unit on which it depends is re-compiled.
>
>I know I must have misunderstood the counsel in the original message
>in which subunit context clauses was referenced.


   Let see if I can make it simple...  If you have a "maverick" operation
that doesn't really belong to any type, and doesn't have any related
operations, that unit should be a library subprogram.  Other operations are
closely related to a type, and therefore must be in the body of the package
that exports the type.  But what about operations which must "see" inside
an object, but don't belong to the abstraction?  Where do they go?

   Of course, the right answer is that they go away.  You partition out the
 operations of the abstraction and if necessary add them to the interface
for the type.  Then the maverick subprogram can be put into the program
library as a subprogram, not a subunit.

   So to me, any with clauses that apply to only one subprogram in the body
are very suspect, and almost always indicate a design flaw.  The exceptions
are some of the primitive operations in Ada that look like library units,
which often get used exactly once per abstraction:  Unchecked_Conversion,
Unchecked_Deallocation, etc.  Unchecked_Deallocation in practice is always
a one line instance that gets called in several places:

    procedure Free is new Unchecked_Deallocation(...);

    ...so it is never really a candidate for a subunit.  With
Unchecked_Conversion since there are two types involved in each instance,
you sometimes see cases where a single (visible) operation that uses
Unchecked_Conversion has several instances of Unchecked_Conversion, and is
big enough to be written as a subunit.  (Typically, a conversion or I/O
routine which deals with variants.)  So I am willing to make an exception
for Unchecked_Conversion.  But that's it.
Any other with that applies to only one subprogram indicates poor cohesion,
or that some type doesn't export a needed operation.

                                        Robert I. Eachus

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