From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e94a7e4f6f888766
X-Google-Attributes: gid103376,public
From: Marin David Condic <condicma@bogon.pwfl.com>
Subject: Re: Self-referential types
Date: 1999/10/15
Message-ID: <38078775.73450564@pwfl.com>#1/1
X-Deja-AN: 537206453
Content-Transfer-Encoding: 7bit
Sender: condicma@bogon.pwfl.com
References: <7ttb4a$8mq$1@nnrp1.deja.com>   <s04ql7cqh1s45@corp.supernews.com>
 <3802f2db_2@news1.prserv.net>   <3803B5E3.F96A6DD4@mitre.org>
 <3803c8bc_2@news1.prserv.net> <3804E7E0.6A0265FB@mitre.org>
 <Pine.BSF.4.10.9910132009020.18305-100000@shell5.ba.best.com>
 <38077EB3.E6911567@mitre.org>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: Pratt & Whitney
Mime-Version: 1.0
Reply-To: e108678@pwflcom
Newsgroups: comp.lang.ada
Date: 1999-10-15T00:00:00+00:00
List-Id: <comp.lang.ada>

"Robert I. Eachus" wrote:

>    AFIAK, it is almost always poor engineering to declare procedures
> within other procedures in Ada. The chief exception is recursive descent
> parsers, and even in that case there are good arguments for using
> unnested procedures.  Also there are cases where you want to break a
> procedure into subunits for implementation reasons:
>

This debate has been around before and a case has been made on the other
side. Similar to the Cobol "perform", nested procedures give you a way of
grouping blobs of code under some sort of descriptive name which helps
clarify the main body of the code - especially where the main body of the
code might otherwise become too deeply nested in control sturctures. For
example:

procedure Process_Payroll is
    procedure Read_In_Transaction_Trapping_Device_Errors (
        Trans : out Trans_Type) is
    begin
        --Use Your Imagination
    end Read_In_Transaction_Trapping_Device_Errors ;
    function Transaction_Successfully_Read return Boolean is
    begin
        --More of the same...
    end Transaction_Successfully_Read ;
    procedure Edit_Transaction_For_Keypunch_Errors (
        Trans : in out Trans_Type) is
    begin
        --Fill in the blanks.
    end Edit_Transaction_For_Keypunch_Errors ;
begin
    --blahblahblah

    while (not End_Of_File (Trans_File)) loop
        Read_In_Transaction_Trapping_Device_Errors (Trans) ;
        if (Transaction_Successfully_Read) then
            Edit_Transaction_For_Keypunch_Errors (Trans) ;
        end if ;
        --yadayadayada
    end loop ;

    --blahblahblah
end Process_Payroll ;

You can always export the nested procedures by making them "is separate" or
just stand-alone procedures brought in with a "with" clause, but if the code
volume is not too large and the access to common data is high, I'd prefer to
see it local to the same file from which it is called. I wouldn't think of
that as bad software engineering or bad style. It all depends on if it is
helping you clarify what you are doing and is not being badly overused.

Obviously, after "a certain size" you probably want these things in separate
units for configuration management, reusability and other concerns. What is
the threshold? I'd say "As many lines as you can read while holding your
breath." :-)

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/