At 04:16 PM 12/10/98 -0500, W. Wesley Groleau x4923 wrote:
>I agree with this point.  However, I would not be likely to use this
>nesting method if there was the remotest chance one of my subprograms
>could ever be a candidate for re-use.  It is just in contrast to the
>method some people use of writing 4,000 SLOC straight line procedures.
>It's kind of like making the parent procedure a table of contents to the
>substeps--only it's at the end.  Or like the parent is the "what" and the
>nested routines are the "how".  In other words, it's not a modularity or
>factoring technique, it's just a way of avoiding the alternate example
>I generally use this technique only when it's obvious that there will
>never be any need to "lift" a routine to a higher nesting level.  As for
>lifting variables, it's just as easy to lift a variable from a nested
>routine to the parent routine.

    The technique of using  subroutines expository purposes is fine,
whether or not you expect the code to be reused is fine, and is almost
orthogonal to the nesting question.  (Acutally when I use the subroutines
like that, the decision as to whether or not to use nesting usually depends
on whether there are several parameters to the enclosing that need to be
used in the inner routines.)

    The nesting issue really involves nested variable declarations.
Sometimes variables do need to be nested:

    with Ada.Text_IO;...
    function Get_Matrix return Matrix is
      Number_of_Rows, Number_of_Columns: Integer;
         Result: Matrix(Number_of_Rows, Number_of_Columns) := (others => 0);
         for I in 1..Number_of_Rows loop
           for J in 1..Number_of_Columns loop
           end loop;
         end loop;
    end Get_Matrix;

    But, and this is the key, such nesting almost always involves delcare
blocks, not subprograms, or not just subprograms.

                                        Robert I. Eachus

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