Interface Compatibility
Many types of change 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. All previously available interfaces remain
intact.
-
Incompatible updates. These updates
change the existing interface. Existing users of the
interface can fail, or behave incorrectly.
The following table categorizes some common object changes.
Table 12 Examples of Interface Compatibility
|
|
|
The addition of a symbol
|
Compatible
|
|
The removal of a symbol
|
Incompatible
|
|
The addition of an argument to a
non-variadic function
|
Incompatible
|
|
The removal of an argument from a
function
|
Incompatible
|
|
The change of size, or content, of a data
item to a function or as an external
definition
|
Incompatible
|
|
A bug fix, or internal enhancement to a
function, providing the semantic properties of the
object remain unchanged
|
Compatible
|
|
A bug fix, or internal enhancement to a
function when the semantic properties of the
object change
|
Incompatible
|
|
Note -
Because of interposition, the addition of a symbol can
constitute an incompatible update. The new symbol might conflict
with an applications use of that symbol. However, this form of
incompatibility does seem rare in practice as source-level name
space management is commonly used.
Compatible updates can be accommodated by maintaining version
definitions that are 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 enable the selective
binding of applications. These techniques also enable verification of
correct version binding at runtime. These two techniques are explored in
more detail in the following sections.