From: Joachim Schrod 
To: LitProg@SHSU.edu
Subject: indices for OO programming languages (was Re: Overloading C++
         functions in FWEB/CWEB++)
Date: Sun, 14 Feb 1993 20:21:47 +0100 (MEZ)

...[answer to a specific discussion on function/operator overloading
    in CWEB and FWEB]...

In my mail I wanted to add a viewpoint to the (IMO interesting)
question how to do indices for software systems written in an
object-oriented programming language. My viewpoint is perhaps not a
widespread one:

	I don't find identifier indices of much help.

I should prepend my preconditions: In OO languages, one does not
write programs any more, but modules. While designing the modules one
pays attention to proper and established SE conventions, ie, one
doesn't lump together specification and implementation -- these are
and shall be separate documents. (Without that one can forget most
abstractions.) Within a small (one-person) project, one must handle a
few hundred classes, many of them from class libraries; larger
systems have thousands of them.

Therefore, one does need interactive query facilities on the current
state of a software system. When I want to see the declaration of
an entity named by an identifier, I just click on the identifier and
a window is opened where the declaration is shown. (With the
restriction outlined above -- very often the declaration cannot be
determined since it does not exist even at compilation time.) I can
also ask where this entity is used elsewhere in this module.
    An interactive access to the inheritance tree (in the current
state) is also urgently needed. There one can query the method
declarations which might be addressed by a given usage. (That's the
software piece called a ``class browser,'' by the way.) But the
definitive answer will only be available by a debugger, which must
therefore be integrated in the development environment.
    For me, an index is a weak substitute for the facilities of an
interactive development environment, needed if I have to handle
printed documents (which I try not to do at all in the context of
software construction).

Oh yes, concerning printed documents: Experience shows that it is not
possible to create a current printout of a non-trivial software
system. This problem was described already decades ago in Brook's
famous book on the Mythical Man Month. While one person is creating
the document, his/her collegues change the system in their own
workspaces. (Of course I assume the usage of a configuration
management system.)
    One shouldn't believe that one is able to create such a thing as
a ``current printout'' if one creates a non-monolithic system. But
exactly there I see the future of Literate Programming: Merging the
new possibilities of Electronic Publishing (Hypertext, generic
markup, connections to databases, information retrieval systems, ...)
into the software construction process, and exploring new ways of
software system presentation for human beings.


Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany