Kevin, you're absolutely right! It is tedious! But not documenting things that are necessary for the interactions between packages (aka services) would surely lead to errors and chaos if programmers just went ahead and did whatever they wanted. (And that's indeed how Class III code sometimes is done!)
When time, programmer resources and functionality demands are tight we do go to the extent of documenting such relationships. Also, in the VistA/M environment there are system-wide variables that can be most useful and are also documented as being "Supported" (that means any app can use them as documented in the IA). As you have already learned, applications such as VA FileMan, Kernel, Toolkit, Mailman, etc. have a rather significant list of such "function objects" (of various kinds) each of them are formally recorded in Integration Agreements so that everyone can know their status. Several decades ago it WAS a free-for-all. Developers like Bob Lushene felt it was their privilege to poke around in any application's data regardless of whether they had approval to do so, lot alone whether they were even doing it "right". Even the tedious stuff gets formally documented ... or else it's "off limits". Better to document what's needed than to let programmers pick up whatever they find lying around and expect to have to support it! Documenting even the most trivial interface detail establishes responsibilities for the short and long term. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Tuesday, May 24, 2005 2:56 PM To: [email protected] Subject: Re: [Hardhats-members] Question on updating the database Sigh... I know that much has been done with M in vista, but this system of setting down written agreements of which programs can access this or that global variable seems tedius and error prone. I am used to being able to create an function object that encapsulates its private details, and then exposes an interface that anyone in the world is welcome to use. But we work with what we have. Kevin --- Greg Woodhouse <[EMAIL PROTECTED]> wrote: > Of course you're right. This doesn't give OE/RR the > right to do this > anywhee they want, just in one particular situation. > I misspoke. > > --- [EMAIL PROTECTED] wrote: > > > I expect that the USAGE: Private, means no other > > subroutines and process may use this component. > > > > The Protocol Menu may be talking about an entry in > the > > PROTOCOL file with a TYPE="M" (MENU) > > > > > > A practical man is a man who practices the errors of > his forefathers. --Benjamin Disraeli > ==== > Greg Woodhouse > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create > apps using Yahoo! > Search APIs Find out how you can build Yahoo! > directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
