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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	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: "Robert I. Eachus" <eachus@mitre.org>
Subject: Re: Self-referential types
Date: 1999/10/18
Message-ID: <380BA036.E9F51F22@mitre.org>#1/1
X-Deja-AN: 537687435
Content-Transfer-Encoding: 7bit
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> <7u86su$o5v$1@nntp8.atl.mindspring.net>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: usenet@news.mitre.org
X-Trace: top.mitre.org 940285697 26016 129.83.41.77 (18 Oct 1999 22:28:17 GMT)
Organization: The MITRE Corporation
Mime-Version: 1.0
NNTP-Posting-Date: 18 Oct 1999 22:28:17 GMT
Newsgroups: comp.lang.ada
Date: 1999-10-18T22:28:17+00:00
List-Id: <comp.lang.ada>

   It is nice to be so respectfully disagreed with by so many people,
and so
quickly too. ;-)  However, I don't think they are really disagreeing
with my point, just with the words I used to say it.

   Let's say you have an otherwise large subprogram, with a lot of
complexity and a lot of hidden scope variables and data, you have two
choices of how to implement it:

   You can create a procedure or function with a lot of other nested
subprograms, or

   You can create a package with the shared state in the body, and the
previous complex procedure as a public interface to that package.

   In Ada you should almost always (there are those words again) choose
the later.  The exceptions tend to be those cases where the enclosing
subprogram has lots of record or array parameters.  But that is normaly
bad programming practice.

   To specifically address Richard Riehle's comments, I tend to do the
same thing as he does with case statements, but I unnest the case
alternatives and put them in a package.  If there is local state needed
from the enclosing procedure, I make it a generic package and
instantiate it locally to pass the parameters of the enclosing
procedure.

   Doing all this takes effort.  You have to think about what state is
getting passed where.  (Unless, of course, you did all that right during
detailed design. ;-) I refuse to see that as anything other than a
benefit.  I can't begin to count the number of times I have caught
subtle programming or design bugs this way, and of course the
maintenance programmer will love you for it.  Well, maybe that is a bit
strong.  Certainly he or she won't detest you, and may even say hello in
the hallway or the cafeteria.  Of course, if you get stuck with the
maintenance job, you will find yourself saying, "Gee, I'm glad I did
this right," rather than "What the hell was I thinking when I wrote
this."

  I could give examples, but why bother.  Everyone reading this must
have had the experience of a subtle bug caused by undocumented (and
usually unintended) coupling between otherwise unrelated units.
   
-- 

                                        Robert I. Eachus

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