Archive-Date: Mon, 28 Dec 1992 14:55:49 CST
Message-ID: <9212282048.AA13426@im4u.cs.utexas.edu>
From: leew@cs.utexas.edu (Lee Wittenberg)
Reply-To: LitProg@SHSU.edu
Date: Mon, 28 Dec 1992 14:47:59 -0600
To: LitProg@shsu.edu
Subject: Re: OO Literate Programming?

Paul Lyon made a number of interesting points points in his message (most
notably for me the one about "dumb" linkers that insist on linking in all
of an object module rather than just what is needed).  Since I've been
doing object-oriented literate programming for a bit, I figure I ought to
respond.  I'm not necessarily disagreeing with Paul -- this is just how
I've been doing it.

I prefer to put a single class in a source file (I believe this is what
Paul said he prefers, as well), although sometimes I put related classes in
a single web.  I use the @( feature (available in Spidery WEB and CWEB the
last time I checked) to create the header files (separate headers for each
class, regardless of whether they share a source file or not).  The
structure of a class "Object", for example, would look like this:

@; @(Object.h@>@; @@; Using @(Object.h@> in the code instead of a #include "Object.h" is a nice little feature of file modules: the code gets expanded both in the main program _and_ in the Object.h file. Spidery WEB complains about this (but does it anyway), but CWEB works fine (at least it did the last time I checked -- I've been using the Spidery version for Standard C and C++). I can then describe and define the Object class as I see fit, knowing that the interface will be generated automatically (and will agree with the implementation). The down side is that the header file gets updated every time the web changes, so things get recompiled that needn't be. However, there are ways around this in a makefile, and anyway, it wastes computer time rather than my time, which is much more valuable. I've been treating the dumb linker I have to use the same way I would treat a dumb (i.e., non-optimizing) compiler. I ignore it. I figure the time I save (overall) by using literate programming more than makes up for the larger executables. Most of my libraries tend to be small, (after the third or fourth draft, anyway), so this really isn't a problem in practice. Although I will admit that if I could find a reliable intelligent linker at a reasonable price (ah, there's the rub!), I would buy it in a New York minute. Hope this adds some fuel to the fire. -- Lee ------------------------------------------------------------------------