Interface Compatibility

There are many types of change that can be made to an object. In their simplest terms these changes can be categorized into one of two groups:

• compatible updates. These updates are additive, in that all previously available interfaces remain intact.

• incompatible updates. These updates have changed the existing interface in such a way that existing users of the interface can fail or behave incorrectly.

The following list attempts to clarify some common object changes into one of the above categorizations:

• the addition of a symbol - a compatible update.

• the removal of a symbol - an incompatible update.

• the addition of an argument to a non-varargs(5) function - an incompatible change.

• the removal of an argument from a function - an incompatible update.

• the change of size, or content, of a data item to a function or as an external definition - an incompatible change.

• a bug fix, or internal enhancement to a function - a compatible change providing the semantic properties of the object remain unchanged, otherwise, this is an incompatible change.

It is possible, because of interposition, that the addition of a symbol can constitute an incompatible update, such that the new symbol might conflict with an applications use of that symbol. However, this does seem rare in practice as source level name space management is commonly used.

Compatible updates can be accommodated by maintaining version definitions internal to the object being generated. Incompatible updates can be accommodated by producing a new object with a new external versioned name. Both of these versioning techniques allow for the selective binding of applications as well as verification of correct version binding at runtime. These two techniques are explored in more detail in the following sections.