1) I am concerned with open implementation (OI) modules in which the semantics of the base-interface can be changed through the use of the meta-interface. That is, I think that the functions in the base-interface should maintain the same postconditions regardless of invocations on the meta-interface. The FIXNUM example, along with many other language pragmas, make me wonder how strictly I really believe this, but I believe in at least some near variant of this claim.
2) Exposing some representation is more acceptable than it used to be. This is, at least in part, because making changes to data representation is less common than it was two decades ago. One reason is that we simply know more about good ways to represent data (our knowledge has come both from experience and also from research in algorithms and data structures). Another reason is that memory is less expensive, which (for many applications) allows us to use simpler (and usually bigger) representations without severe consequences.
3) How do we decide what to expose in each of the interfaces for an OI module? Just like in ``conventional'' information hiding (which, to be fair to Parnas, I think is not necessarily identical to black-box abstraction, as presented in the white paper), it seems to be a matter of anticipation. Any given meta-interface will allow clients to have some limited degree of control over the permitted implementations. If the range of implementations is broad enough to satisfy clients, then the module will be successful; if not, it will fail to meet expectations.
4) So, how do we properly anticipate what clients need? The only answer I can presently imagine is, ``experience.'' That is, I think that OI is an effective approach to RE-designing modules rather than for initially designing modules. It's hard enough, the first two or three or four or five generations for most systems, to get the base-interface ``right'' (in terms of function, even ignoring performance). Simultaneously trying to define a meta-interface early on seems impractical (or even dangerous), in general. (Note that the re-design might be ``in place,'' creating a restructured system in which some conventional modules are replaced by OI modules, or it might be during an entirely new generation of the overall system. The latter has, for instance, been the common approach in operating system uses of OI.)
(As an aside, I thought the comment saying (something like), ``Hey, it's OK to hide some implementation details, such as variable names,'' was not especially useful in guiding what to expose. There must be plenty of times where there are aspects of an implementation---beyond variable names---that should be hidden.)
5) To me it's obvious that open design (which, by the way, I think is a better term than open implementation) is going to be harder to get right than conventional black-box design. This concerns me, since there are still precious few people that seem to be fundamentally effective at black-box design. (Parnas once told me that he almost always sees the following phenomenon when teaching one-week courses in information hiding: everybody does great the first four days, nodding their heads, asking good questions, etc.; but on the fifth day, when he asks them to go to the board and do a design, they always do a functional decomposition. Moral: at least for people trained in functional decomposition, black-box abstraction is hard to learn and thus to do well.) So, how many people will be capable of doing open design? Will bad open designs be more problematic than decent black-box designs (with associated hematomas, etc.)? Seems entirely plausible to me.
6) Is every element in an OI module's interface clearly distinguished as being in the base-interface or in the meta-interface? I think it is critical to do so, but do not have enough experience to determine whether this is, in general, true.
7) In places in the white paper, I got confused about OI ``types'' vs. OI ``instances.'' (These terms weren't used, at least in general, but I tried to apply them to clarify some things, and wasn't perfectly successful.)
8) The white paper reminds me of a common myth in software design: ``Higher-level abstractions give more power to a software engineer.'' They don't give more power (in any computational sense); what they do (if well designed) is to increase expressiveness by allowing one to say less to get more.
9) Is there a fundamental distinction between a meta-interface consisting of hints vs. those consisting of explicit directives? Sure there is. How does a software engineer decide between them?
Enough rambling.
Back to Alphabetical List of Responses
(Last Revised October 1994)