;Re: Style: always declare subrountines?

[Richard Riehle <richard@adaworks.com>]

Victor Porton wrote:

> How do you consider this:
>
> If one would always declare every subrountine of a package body in the
> specification (in the public or in the private part) this excludes the
> possibility that one may mistakedly create an internal subrountine with
> the same specification as a not yet implemented public procedure and
> forget to implement this public procedure and so get wrong program
> behavior.

My own own preference for internal subprograms that have no
entry in the specification  to promote them to a private package
specification.   This promotes reuse, enhances maintenance, and
allows extensibility.   For example, consider:

            package P1 is
                procedure Q ...
                procedure R ...
                function    S   return ...
           end P1;

           package body P1 is
               function T ... return  ... is ... end T;
               function Z ... return  ... is ... end Z;
               function W ... return  ... is ... end W;
               procedure Q ... is ...   end Q;
               procedure R ... is ...   end R;
               function    S ... return ... is ...   end S;
          end P1;

The three functions, T, Z, and W can be promoted to a private package
specification,

            private package P1.Utilities is
               function T ... return  ... ;
               function Z ... return  ... ;
               function W ... return  ... ;
          end P1.Utilities;

Now package body for P1 is as before but,

          with P1.Utilities;
          package body P1 is  ... end P1;

For some reason, we continue to see some designers
miss out on the potential for decomposing their systems
so they can make the best use of private child library units.
The fundamental design policy can be stated as: only include
in package body the code corresponding directly to entries
in the specification.  Everything else should have its
own specification and implementation.

Richard Riehle