Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!spool2.mu.edu!uunet!convex!bleikamp From: bleikamp@convex.com (Richard Bleikamp) Newsgroups: comp.lang.fortran Subject: Re: global data Summary: Modules vs. INCLUDE Message-ID: <1991Jan08.190720.29316@convex.com> Date: 8 Jan 91 19:07:20 GMT References: <10553@lanl.gov> <1991Jan08.143747.16553@convex.com> Sender: news@convex.com (news access account) Distribution: usa Organization: Convex Computer Corporation, Richardson, Tx. Lines: 26 Nntp-Posting-Host: mozart.convex.com In article maine@elxsi.dfrf.nasa.gov (Richard Maine) writes: >Richard> The use of modules to implement a 3rd party library >Richard> essentially requires the 3rd party to ship source code. > >It's not clear to me that this is so. Why couldn't source code be shipped >only for the interface to the module, without shipping source code for >the implementation? There should be little objection to source code >for the interface. That's essentially documentation and is also pretty >simillar in content to what would be shipped with include files. > you're right. I didn't explain my point very well. What you suggest works ok. It just doesn't buy you very much thay INCLUDE doesn't. In particular, you are giving up optional and keyword arguments when only the interfaces are contained in a module. The one obvious advantage gained is that MODULE names are standardized while INCLUDE objects are not. The 3rd party vendor; however, can more easily document how to use INCLUDE (all UNIX systems will be the same). Using MODULEs will be less consistent across vendors, and more difficult to document for the third party vendor. -- ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation