Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!taumet!mike
From: mike@taumet.UUCP (Michael S. Ball)
Newsgroups: comp.lang.c++
Subject: Do class libraries have to be in source form (2 of 4)
Keywords: library, source, C++
Message-ID: <177@taumet.UUCP>
Date: 20 Nov 89 15:33:47 GMT
Organization: Taumetric Corporation, San Diego
Lines: 100


The question to debate:  Are class libraries distributed in object-only
form useful in encouraging software reuse.

The obvious answer to the question is yes:  object-only libraries are
in wide use already, and if we are willing to restrict reuse to that
level I won't argue too much.  I would like to point out, though,
that there are a large number of successful libraries which are
licensed in source form, and the users of such libraries are often
happy to have source available.

Object oriented programming claims to expand reuse by providing:

1.  Objects with (possibly elaborate) internal state

2.  Objects which we can modify as necessary by inheritance.

We have far less experience with these forms of reuse, and essentially
no experience with reusing such objects in object-only form.

First let's consider specification and documentation.

1.  Pure functions with no state - Relatively easy to document as
    the output is defined strictly in terms of the input.  Formal
    methods are usually simple and are commonly used.  Mathematic
    functions are simple examples.

2.  Functions with state - Much harder to document, and though
    formal methods are available they are seldom used.  The most
    common examples are I/O functions.  The documentation is
    typically incomplete and often confusing.  They are easy
    to use in common cases, but difficult in unusual cases.  They
    tend to accumulate a lot of folklore.

3.  Abstract data types -  Similar to functions with state, but
    frequently simpler and intended to be used as components in a
    program design.  There are formal methods available, but they
    are difficult to write and read and are seldom used.  ADTs are
    frequently simple enough that informal methods are adequate to
    give a good understanding.  Complicated types (like windows)
    can require books.

4.  Base classes for inheritance -  In C++ this would be called the
    "protected" interface.  Since this tends to get into implementation
    it is usually much more complex then the external interface, which
    could be described as an abstract data type.  I've seen no use of
    any formal methods, and I suspect they would be difficult to use.
    The description is typically informal and incomplete.
    Basically, we don't know how to do this very well.

I claim that the limitations on specification alone are enough to
make source necessary for successful derivation from a class.  All
the successful examples I have seen have had source available.  An
article in the Sept/Oct 1989 issue of JOOP, "Object-Oriented Software
Reuse: The Yoyo Problem,"  discusses this issue at some length.  I
will refrain from further arguments on this subject since I want to
get others' opinions.

A second area of concern is debugging.  Since classes are meant to
be used as in integral part of a program it is reasonable to want
to look at the internal state of an object when debugging the
program.  For example, when using a container class, we would like to
be able to observe its contents with the debugger.  We might also
like to be able to set breakpoints when items are added or removed
from the class.  The possibilities are larger than any set of
utility and debugging functions dreamed up by the class designer.
Current debuggers require source for this.  Debugging a derived
class could be even more interesting.  Somehow debugging a class
while being able to observe only one member function sounds hard.

One can come up with special cases where debugging won't require
source of the class, but I think that in general it will go much
better with the source.

There are some other arguments for source which are unique to C++.

1.  Sometimes base classes have to become virtual base classes
    to make a class useful for multiple inheritance.

2.  Sometimes a function should be made virtual when the original
    class designer didn't do so.

3.  Sometimes moving something from the private interface to the
    protected interface can simplify derived classes enormously.

4.  The proposed template design requires source (at some level).

In short, my claim is that achieving maximum reuse with a class
library virtually requires source code.  The need is especially
acute when the user plans to derive from the library classes, and
I have seen no evidence at all that object-only classes are
useful as base classes.  The object-oriented environments where
derivation is heavily used all include source for the library.

Comments? (he says as he ducks rapidly)

Michael S. Ball	     		       email: uunet!taumet!mike	
TauMetric Corporation		       Phone: (619)275-6381
1094 Cudahy Pl. Ste 302		       MCI: TauMetric
San Diego, CA 92110