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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,efe03f20164a417b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-03-28 11:30:36 PST
Path: 
 nntp.gmd.de!Germany.EU.net!EU.net!uunet!in1.uu.net!world!blanket.mitre.org!linus.mitre.org!spectre!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: An observation of Ada (may offend)
Date: 28 Mar 1995 19:30:36 GMT
Organization: The Mitre Corp., Bedford, MA.
Message-ID: <EACHUS.95Mar28143036@spectre.mitre.org>
References: <3kbkm1$41o@miranda.gmrc.gecm.com>
 <3kcflv$164a@watnews1.watson.ibm.com>
	<EACHUS.95Mar27145832@spectre.mitre.org>
	<3l9dh4$8p9@butch.lmsc.lockheed.com>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: l107353@cliffy.lfwc.lockheed.com's message of 28 Mar 1995
 16:29:24 GMT
Date: 1995-03-28T19:30:36+00:00
List-Id: <comp.lang.ada>


   I said (discussing source code changes during and after integration):

 > Under most circumstances I can forsee, such an add-on would walk
 > like a kludge, and quack like a kludge.

In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

 > I actually have this wacky idea that we might be able to start
 > reusing packages from project to project without modification, in
 > which case I may want to add new child packages well after FQT. I
 > wouldn't call it a "kludge" -- just an ability to add new features
 > without having to rewrite half of the package every time I want to
 > change the available features!

   First read what I wrote.  I can imagine cases where such a change
would be appropriate, especially during development and I said that.
I can also imagine adding a chiild unit in exactly those
circumstances.  (I can even imagine a "corporate programming standard"
which required all instantiations of generics nested in packages to be
child units of that package.--I don't encourage such a practice, but I
can imagine it. ;-) But I still believe that adding a child unit
during integration is likely to be a kludge.

   Now you just voluteered for the maintenance job, and it is hard to
get good maintainers, wonderful.  When you go to add your new child
unit, how do you know that it is not replacing another child of the
same name, which you were unaware of?  I, and many others, like the
documentation you need to be in the logical place--in the source.

 > If the maintainer has no tools or documentation (in our case, he has both),
 > this issue is the least of his problems.

    As anyone who has done software maintenance in the "real world"
can tell you, no tools and no (trustworthy) documenation is standard
practice outside the safety critical fields.  If they had good
documentation, they wouldn't have had to call you.

--

					Robert I. Eachus

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