Let me illustrate with an example: When compilers generate code, they do so ``compositionally'' i.e., the code for an expression is the composition of the code for each of its sub-expressions. To keep code generation manageable, each sub-expression is compiled without knowledge of where it is being used, and the code generator splices code from each sub-expression. Of course, this is known as ``unoptimized'' code. The composition here is trivial. It preserves the semantics, but the resulting code is a dog. Enter the optimizer. It tries to compose the code ``smartly'' by recognizing redundancies and keeping track of the data flow. Kent Dybvig et al. came up with a code generation algorithm that is ``smart'' about where it is being used -- they generate reasonably good code without an optimizer -- the composition of code pieces is non trivial --- it requires keeping track of context information. This gives them the advantage that code-generation is still manageable but they are able to recover certain performance costs.
In both cases, the composition was being handled by the machine and was more or less being carried out as soon as the modules were constructed.
Not so in software development. Compositions are done by hand (by placing calls to other modules where appropriate) and modules are distanced by long periods of time. Moreover, the structure of each module that is being composed is not restricted like it is in the example. This is why, to ensure manageability, traditionally, composition has been trivial. This desideratum naturally induces the notion of BBA.
What OI is trying to achieve is ``smart'' composition. It says that the assumption of trivial compositionality is faulted. Modules that are composed together extensionally must also be composed together intensionally to ensure best performance. If this requires alternative implementations of parts of the module, then BBA must be rejected (to the extent necessary). If the structure of the modules is restricted to be recognizable by machine, smart composition can be carried out without breaking BBA.
Note that this view necessarily requires that the general form of OI must be ``meta-level'' -- to do a good job of composition, the composer (human or machine) must look at the modules from the level of the *writer* of the modules and not from the level of the *user* of the modules. (Aside: This is why most people have the (correct) intuition that access to source code is the ultimate OI) This is also why I think equating OI with parameterization perhaps restricts the smartness of composition in its full generality.
Back to Alphabetical List of Responses
(Last Revised October 1994)