Heading:

IDL DESIGN: Design Principles

Page Numbers: Yes X: 527 Y: 10.5"

XEROX Palo Alto Research Center 25 February 1977
Inter-Office Memorandum

ToIDL GroupIDL Design Note Number: 6

FromBeau SheilFile: <IDL>Design.Principles

Subject Fundamental Design Principles

During the course of the design work, many decisions will have to be made. As a consequence, it occurred to me to write down the major principles that have governed the IDL design so far, so there is some record of them to which to refer. Some of them may seem self evident, some a matter of personal prejudice, but they embody the style in which the existing system has been built. It is important that they be argued about, understood, and that the understanding we reach about them be adhered to. Their unusual importance is a direct consequence of the unusual type of system we are trying to build.

This list does not claim to be complete - merely to contain the most salient. It should grow and change as the result of debate over the course of the project.

The fundamental principle that underlies everything is that the system present a minimal, consistent model of its world to the user. Violations of this minimality and consistency are deadly, as they increase the complexity with which the user has to deal (even if the violation is locally more optimal than the path of consistency), and therefore attack the fundamental theory underlying the system. To (only slightly) overstate the case, it is better that the system be consistently wrong than inconsistently right.

Concretely, this implies that all constructs in the system should be closed, in a consistent manner, under all reasonable interpretations of their behavior. Thus,

For all types of expressions, there will be a consistent rule of evaluation which applies to any of their occurrences.

Expressions should, in general, return values - preferably structures which can be used for multiple purposes. Consequently, functions that serve only one purpose, or which alter their environment (e.g by printing), are frowned upon, although they are occasionally necessary. A further principle of uniformity is that the only function which causes user visible side effects will be assignment. Thus, changes to user visible data structures are all made by the user assigning into selections rather than by "magic" functions. These selectors are all expressions which evaluate normally in a value producing context, producing an object of the same type as those that are assigned into them. (Of course, all of this takes no position on how the structures may actually be represented internally).

The user is not to be trusted - not because he is malicious - but because he is naive. Consequently, all user-supplied arguments to functions are checked by the system. Furthermore, they are checked as soon as possible (e.g. as soon as the user has given them to us) to prevent constant rechecking at each stage. Consequently, all internal system functions assume that their arguments are what they are supposed to be (e.g. according to their declarations) and do no further checking whatsoever (except during system development).