Introduction
As you may have guessed from the name, Objective CAML supports object-oriented programming.
Unlike imperative programming, in which execution is driven by explicit sequencing
of operations, or functional programming, where it is driven by the required
computations, object-oriented programming can be thought of as data driven.
Using objects introduces a new organization of programs into
classes of related objects.
A class groups together data and operations.
The latter, also known as methods, define the possible behaviors of an
object. A method is invoked
by sending a message to an object. When an object receives
a message, it performs the action or the computation corresponding to the method
specified by the message. This is different from applying a function to arguments
because a message (which contains the method name) is sent to an object. It is up to
the object itself to determine the code that will actually be executed; such a
delayed binding between name and code makes behavior
more adaptable and code easier to reuse.
With object-oriented programming, relations are defined between
classes. Classes also define how objects communicate through message parameters.
Aggregation and inheritance relations between classes
allow new kinds of application modeling. A class that inherits
from another class includes all definitions from the parent's class. However, it may extend
the set of data and methods and redefine inherited behaviors, provided typing
constraints are respected.
We will use a graphical notation1 to represent
relations between classes.
Objective CAML's object extensions are integrated with the type system of the language:
a class declaration defines a type with the same name as the class.
Two kinds of polymorphism coexist. One of them is parametric polymorphism,
which we have already seen with parameterized types: parameterized classes.
The other one, known as inclusion polymorphism, uses the subtyping
relation between objects and delayed binding. If the type of the class
sc is a subtype of the class c then any object from sc may
be used in place of an object from c. The subtype constraint must
be stated explicitly. Inclusion polymorphism makes it possible to
construct non-homogeneous lists where the type of each element is a subtype
of a type common to all list elements. Since binding is delayed,
sending the same message to all elements of such a list can activate different
methods according to the sub-classes of the actual elements.
On the other hand, Objective CAML does not include the notion of method overloading,
which would allow several definitions for one method name. Without this restriction,
type inference might encounter ambiguous situations requiring
additional information from the programmer.
It should be emphasized that Objective CAML is the only language with an object
extension that provides both parameterized and inclusion polymorphism, while still being
fully statically typed through type inference.