| Chapter 3 |
Objects in Caml |
|
(Chapter written by Jérôme Vouillon and Didier Rémy)
This chapter gives an overview of the object-oriented features of
Objective Caml.
3.1 Classes and objects
3.2 Reference to self
3.3 Initializers
3.4 Virtual methods
3.5 Private methods
3.6 Class interfaces
3.7 Inheritance
3.8 Multiple inheritance
3.9 Parameterized classes
3.10 Using coercions
3.11 Functional objects
3.12 Cloning objects
3.13 Recursive classes
3.14 Binary methods
3.15 Friends
The class point has one instance variable x and two methods
get_x and move. The initial value of the instance variable is 0.
The variable x is declared mutable, so the method move can change
its value.
#class point =
object
val mutable x = 0
method get_x = x
method move d = x <- x + d
end;;
class point :
object val mutable x : int method get_x : int method move : int -> unit end
We now create a new point p.
#let p = new point;;
val p : point = <obj>
Note that the type of p is point. This is an abbreviation
automatically defined by the class definition above. It stands for the
object type <get_x : int; move : int -> unit>, listing the methods
of class point along with their types.
Let us apply some methods to p:
#p#get_x;;
- : int = 0
#p#move 3;;
- : unit = ()
#p#get_x;;
- : int = 3
The evaluation of the body of a class only takes place at object
creation time. Therefore, in the following example, the instance
variable x is initialized to different values for two different
objects.
#let x0 = ref 0;;
val x0 : int ref = {contents=0}
#class point =
object
val mutable x = incr x0; !x0
method get_x = x
method move d = x <- x + d
end;;
class point :
object val mutable x : int method get_x : int method move : int -> unit end
#new point#get_x;;
- : int = 1
#new point#get_x;;
- : int = 2
The class point can also be abstracted over the initial values of
points.
#class point = fun x_init ->
object
val mutable x = x_init
method get_x = x
method move d = x <- x + d
end;;
class point :
int ->
object val mutable x : int method get_x : int method move : int -> unit end
As for declaration of functions, the above definition can be
abbreviated as:
#class point x_init =
object
val mutable x = x_init
method get_x = x
method move d = x <- x + d
end;;
class point :
int ->
object val mutable x : int method get_x : int method move : int -> unit end
An instance of the class point is now a function that expects an
initial parameter to create a point object:
#new point;;
- : int -> point = <fun>
#let p = new point 7;;
val p : point = <obj>
The parameter x_init is, of course, visible in the whole body of the
definition, including methods. For instance, the method get_offset
in the class below returns the position of the object to the origin.
#class point x_init =
object
val mutable x = x_init
method get_x = x
method get_offset = x - x_init
method move d = x <- x + d
end;;
class point :
int ->
object
val mutable x : int
method get_offset : int
method get_x : int
method move : int -> unit
end
Expressions can be evaluated and bound before defining the object body
of the class. This is useful to enforce invariants. For instance,
points can be automatically adjusted to grid as follows:
#class adjusted_point x_init =
let origin = (x_init / 10) * 10 in
object
val mutable x = origin
method get_x = x
method get_offset = x - origin
method move d = x <- x + d
end;;
class adjusted_point :
int ->
object
val mutable x : int
method get_offset : int
method get_x : int
method move : int -> unit
end
(One could also raise an exception if the x_init coordinate is not
on the grid.) In fact, the same effect could here be obtained by
calling the definition of class point with the value of the
origin.
#class adjusted_point x_init = point ((x_init / 10) * 10);;
class adjusted_point : int -> point
An alternative solution would have been to define the adjustment in
a special allocation function:
#let new_adjusted_point x_init = new point ((x_init / 10) * 10);;
val new_adjusted_point : int -> point = <fun>
However, the former pattern is generally more appropriate, since
the code for adjustment is part of the definition of the class and will be
inherited.
This ability provides class constructors as can be found in other
languages. Several constructors can be defined this way to build objects of
the same class but with different initialization patterns; an
alternative is to use initializers, as decribed below in section
3.3.
A method can also send messages to self (that is, the current object). For
that, self must be explicitly bound, here to the variable s (s could be
any identifier, even though we will often choose the name self.)
#class printable_point x_init =
object (s)
val mutable x = x_init
method get_x = x
method move d = x <- x + d
method print = print_int s#get_x
end;;
class printable_point :
int ->
object
val mutable x : int
method get_x : int
method move : int -> unit
method print : unit
end
#let p = new printable_point 7;;
val p : printable_point = <obj>
#p#print;;
7- : unit = ()
Dynamically, the variable s is bound at the invocation of a method. In
particular, when the class printable_point will be inherited, the variable
s will be correctly bound to the object of the subclass.
Let-bindings within class definitions are evaluated before the object
is constructed. It is also possible to evaluate an expression
immediately after the object has been built. Such code is written as
an anonymous hidden method called an initializer. Therefore, is can
access self and the instance variables.
#class printable_point x_init =
let origin = (x_init / 10) * 10 in
object (self)
val mutable x = origin
method get_x = x
method move d = x <- x + d
method print = print_int self#get_x
initializer print_string "new point at "; self#print; print_newline()
end;;
class printable_point :
int ->
object
val mutable x : int
method get_x : int
method move : int -> unit
method print : unit
end
#let p = new printable_point 17;;
new point at 10
val p : printable_point = <obj>
Initializers cannot be overridden. On the contrary, all initializers are
evaluated sequentially.
Initializers are particularly useful to enforce invariants.
Another example can be seen in section 5.1.
It is possible to declare a method without actually defining it, using
the keyword virtual. This method will be provided latter in
subclasses. A class containing virtual methods must be flagged
virtual, and cannot be instantiated (that is, no object of this class
can be created). It still defines abbreviations (treating virtual methods
as other methods.)
#class virtual abstract_point x_init =
object (self)
val mutable x = x_init
method virtual get_x : int
method get_offset = self#get_x - x_init
method virtual move : int -> unit
end;;
class virtual abstract_point :
int ->
object
val mutable x : int
method get_offset : int
method virtual get_x : int
method virtual move : int -> unit
end
#class point x_init =
object
inherit abstract_point x_init
method get_x = x
method move d = x <- x + d
end;;
class point :
int ->
object
val mutable x : int
method get_offset : int
method get_x : int
method move : int -> unit
end
Private methods are methods that do not appear in object interfaces.
They can only be invoked from other methods of the same object.
#class restricted_point x_init =
object (self)
val mutable x = x_init
method get_x = x
method private move d = x <- x + d
method bump = self#move 1
end;;
class restricted_point :
int ->
object
val mutable x : int
method bump : unit
method get_x : int
method private move : int -> unit
end
#let p = new restricted_point 0;;
val p : restricted_point = <obj>
#p#move 10;;
This expression has type restricted_point
It has no method move
#p#bump;;
- : unit = ()
Private methods are inherited (they are by default visible in subclasses),
unless they are hidden by signature matching, as described below.
Private methods can be made public in a subclass.
#class point_again x =
object (self)
inherit restricted_point x
method virtual move : _
end;;
class point_again :
int ->
object
val mutable x : int
method bump : unit
method get_x : int
method move : int -> unit
end
The annotation virtual here is only used to mentioned a method without
providing its definition. An alternative definition is
#class point_again x =
object (self : < move : _; ..> )
inherit restricted_point x
end;;
class point_again :
int ->
object
val mutable x : int
method bump : unit
method get_x : int
method move : int -> unit
end
One could think that a private method should remain private in a subclass.
However, since the method is visible in a subclass, it is always possible
pick it's code and define a method of the same name that run that code, so
yet another (heavier) solution would be:
#class point_again x =
object (self : < move : _; ..> )
inherit restricted_point x as super
method move = super#move
end;;
class point_again :
int ->
object
val mutable x : int
method bump : unit
method get_x : int
method move : int -> unit
end
Of course, private methods can also be virtual. Then, the keywords must
appear in this order method private virtual.
Class interfaces are inferred from class definitions. They may also
be defined directly and used to restrict the type of a class. As class
declarations, they also define a new type constructor.
#class type restricted_point_type =
object
method get_x : int
method bump : unit
end;;
class type restricted_point_type =
object method bump : unit method get_x : int end
#fun (x : restricted_point_type) -> x;;
- : restricted_point_type -> restricted_point_type = <fun>
In addition to documentation, these class interfaces can be used to
constrain the type of a class. Both instance variables and concrete
private methods can be hidden by a class type constraint. Public and
virtual methods, however, cannot.
#class restricted_point' x = (restricted_point x : restricted_point_type);;
class restricted_point' : int -> restricted_point_type
Or, equivalently:
#class restricted_point' = (restricted_point : int -> restricted_point_type);;
class restricted_point' : int -> restricted_point_type
The interface of a class can also be specified in a module
signature, and used to restrict the inferred signature of a module.
#module type POINT = sig
class restricted_point' : int ->
object
method get_x : int
method bump : unit
end
end;;
module type POINT =
sig
class restricted_point' :
int -> object method bump : unit method get_x : int end
end
#module Point : POINT = struct
class restricted_point' = restricted_point
end;;
module Point : POINT
We illustrate inheritance by defining a class of colored points that
inherits from the class of points. This class has all instance
variables and all methods of class point, plus a new instance
variable c and a new method color.
#class colored_point x (c : string) =
object
inherit point x
val c = c
method color = c
end;;
class colored_point :
int ->
string ->
object
val c : string
val mutable x : int
method color : string
method get_offset : int
method get_x : int
method move : int -> unit
end
#let p' = new colored_point 5 "red";;
val p' : colored_point = <obj>
#p'#get_x, p'#color;;
- : int * string = 5, "red"
A point and a colored point have incompatible types, since a point has
no method color. However, the function get_x below is a generic
function applying method get_x to any object p that has this
method (and possibly some others, which are represented by an ellipsis
in the type). Thus, it applies to both points and colored points.
#let get_succ_x p = p#get_x + 1;;
val get_succ_x : < get_x : int; .. > -> int = <fun>
#get_succ_x p + get_succ_x p';;
- : int = 8
Methods need not be declared previously, as shown by the example:
#let set_x p = p#set_x;;
val set_x : < set_x : 'a; .. > -> 'a = <fun>
#let incr p = set_x p (get_succ_x p);;
val incr : < get_x : int; set_x : int -> 'a; .. > -> 'a = <fun>
Multiple inheritance is allowed. Only the last definition of a method
is kept: the redefinition in a subclass of a method that was visible in
the parent class overrides the definition in the parent class.
Previous definitions of a method can be reused by binding the related
ancestor. Below, super is bound to the ancestor printable_point.
The name super is not actually a variable and can only be used to
select a method as in super#print.
#class printable_colored_point y c =
object (self)
val c = c
method color = c
inherit printable_point y as super
method print =
print_string "(";
super#print;
print_string ", ";
print_string (self#color);
print_string ")"
end;;
class printable_colored_point :
int ->
string ->
object
val c : string
val mutable x : int
method color : string
method get_x : int
method move : int -> unit
method print : unit
end
#let p' = new printable_colored_point 17 "red";;
new point at (10, red)
val p' : printable_colored_point = <obj>
#p'#print;;
(10, red)- : unit = ()
A private method that has been hidden in the parent class is no more
visible, and is thus not overridden. Since initializers are treated as
private methods, all initializers along the class hierarchy are evaluated,
in the order they are introduced.
| 3.9 |
Parameterized classes |
|
Reference cells can also be implemented as objects.
The naive definition fails to typecheck:
#class ref x_init =
object
val mutable x = x_init
method get = x
method set y = x <- y
end;;
Some type variables are unbound in this type:
class ref :
'a ->
object val mutable x : 'a method get : 'a method set : 'a -> unit end
The method get has type 'a where 'a is unbound
The reason is that at least one of the methods has a polymorphic type
(here, the type of the value stored in the reference cell), thus the
class should be parametric, or the method type should be constrained
to a monomorphic type. A monomorphic instance of the class could
be defined by:
#class ref (x_init:int) =
object
val mutable x = x_init
method get = x
method set y = x <- y
end;;
class ref :
int ->
object val mutable x : int method get : int method set : int -> unit end
A class for polymorphic references must explicitly list the type
parameters in its declaration. Class type parameters are always listed
between [ and ]. The type parameters must also be bound somewhere
in the class body by a type constraint.
#class ['a] ref x_init =
object
val mutable x = (x_init : 'a)
method get = x
method set y = x <- y
end;;
class ['a] ref :
'a -> object val mutable x : 'a method get : 'a method set : 'a -> unit end
#let r = new ref 1 in r#set 2; (r#get);;
- : int = 2
The type parameter in the declaration may actually be constrained in the
body of the class definition. In the class type, the actual value of
the type parameter is displayed in the constraint clause.
#class ['a] ref_succ (x_init:'a) =
object
val mutable x = x_init + 1
method get = x
method set y = x <- y
end;;
class ['a] ref_succ :
'a ->
object
constraint 'a = int
val mutable x : int
method get : int
method set : int -> unit
end
Let us consider a more realistic example. We put an additional type
constraint in method move, since no free variables must remain uncaptured
by a type parameter.
#class ['a] circle (c : 'a) =
object
val mutable center = c
method center = center
method set_center c = center <- c
method move = (center#move : int -> unit)
end;;
class ['a] circle :
'a ->
object
constraint 'a = < move : int -> unit; .. >
val mutable center : 'a
method center : 'a
method move : int -> unit
method set_center : 'a -> unit
end
An alternate definition of circle, using a constraint clause in
the class definition, is shown below. The type #point used below in
the constraint clause is an abbreviation produced by the definition
of class point. This abbreviation unifies with the type of any
object belonging to a subclass of class point. It actually expands to
< get_x : int; move : int -> unit; .. >. This leads to the following
alternate definition of circle, which has slightly stronger
constraints on its argument, as we now expect center to have a
method get_x.
#class ['a] circle (c : 'a) =
object
constraint 'a = #point
val mutable center = c
method center = center
method set_center c = center <- c
method move = center#move
end;;
class ['a] circle :
'a ->
object
constraint 'a = #point
val mutable center : 'a
method center : 'a
method move : int -> unit
method set_center : 'a -> unit
end
The class colored_circle is a specialized version of class
circle which requires the type of the center to unify with
#colored_point, and adds a method color. Note that when specializing a
parameterized class, the instance of type parameter must always be
explicitly given. It is again written inside [ and ].
#class ['a] colored_circle c =
object
constraint 'a = #colored_point
inherit ['a] circle c
method color = center#color
end;;
class ['a] colored_circle :
'a ->
object
constraint 'a = #colored_point
val mutable center : 'a
method center : 'a
method color : string
method move : int -> unit
method set_center : 'a -> unit
end
Subtyping is never implicit. There are, however, two ways to perform
subtyping. The most general construction is fully explicit: both the
domain and the codomain of the type coercion must be given.
We have seen that points and colored points have incompatible types.
For instance, they cannot be mixed in the same list. However, a
colored point can be coerced to a point, hiding its color method:
#let colored_point_to_point cp = (cp : colored_point :> point);;
val colored_point_to_point : colored_point -> point = <fun>
#let p = new point 3 and q = new colored_point 4 "blue";;
val p : point = <obj>
val q : colored_point = <obj>
#let l = [p; (colored_point_to_point q)];;
val l : point list = [<obj>; <obj>]
An object of type t can be seen as an object of type t'
only if t is a subtype of t'. For instance, a point cannot be
seen as a colored point.
#(p : point :> colored_point);;
Type point = < get_offset : int; get_x : int; move : int -> unit >
is not a subtype of type
colored_point =
< color : string; get_offset : int; get_x : int; move : int -> unit >
Indeed, backward coercions are unsafe, and should be combined with a type case,
possibly raising a runtime error. However, there is no such operation
available in the language.
Be aware that subtyping and inheritance are not related. Inheritance is a
syntactic relation between classes while subtyping is a semantic relation
between types. For instance, the class of colored points could have been
defined directly, without inheriting from the class of points; the type of
colored points would remain unchanged and thus still be a subtype of
points.
The domain of a coercion can usually be omitted. For instance, one can
define:
#let to_point cp = (cp :> point);;
val to_point :
< get_offset : int; get_x : int; move : int -> unit; .. > -> point = <fun>
In this case, the function colored_point_to_point is an instance of the
function to_point. This is not always true, however. The fully
explicit coercion is more precise and is sometimes unavoidable.
Here is an example where the shorter form fails:
#class virtual c = object method virtual m : c end;;
class virtual c : object method virtual m : c end
#class c' =
object (self)
inherit c
method m = (self :> c)
method m' = 1
end;;
This expression cannot be coerced to type c = < m : c >; it has type
< m : c; m' : 'a; .. >
but is here used with type < m : 'b; m' : 'a; .. > as 'b
Type c = < m : c > is not compatible with type 'b
Self type cannot be unified with a closed object type
The type of the coercion to type c can be seen here:
#function x -> (x :> c);;
- : (< m : 'a; .. > as 'a) -> c = <fun>
As class c'
inherits from class c, its method m must have type c. On the
other hand, in expression (self :> c) the type of self
and the domain of the coercion above must be unified.
That is, the type of the method m in self (i.e. c) is
also the type of self. So, the type of self is c.
This is a contradiction, as the type of self has a
method m', whereas type c does not.
The desired coercion of type <m : c;..> -> c can be obtained by
using a fully explicit coercion:
#function x -> (x : #c :> c);;
- : #c -> c = <fun>
Thus one can define class c' as follows:
#class c' =
object (self)
inherit c
method m = (self : #c :> c)
method m' = 1
end;;
class c' : object method m : c method m' : int end
An alternative is to define class c this way (of course
this definition is not equivalent to the previous one):
#class virtual c = object (_ : 'a) method virtual m : 'a end;;
class virtual c : object ('a) method virtual m : 'a end
Then, a coercion operator is not even required.
#class c' = object (self) inherit c method m = self method m' = 1 end;;
class c' : object ('a) method m : 'a method m' : int end
Here, the simple coercion operator (e :> c) can be used to
coerce an object expression e from type c' to type c.
Semi-implicit coercions are actually defined so
as to work correctly with classes returning self.
#(new c' :> c);;
- : c = <obj>
Another common problem may occur when one tries to define a coercion to a
class c inside the definition of class c. The problem is due to the type
abbreviation not being completely defined yet, and so its subtypes are not
clearly known. Then, a coercion (_ : #c :> c) is taken to be
the identity function, as in
#function x -> (x :> 'a);;
- : 'a -> 'a = <fun>
As a consequence, if the coercion is applied to self, as in the
following example, the type of self is unified with the closed type
c (a closed object type is an object type without ellipsis). This
would constrains the type of self be closed and is thus rejected.
Indeed, the type of self cannot be closed: this would prevent any
further extension of the class. Therefore, a type error is generated
when the unification of this type with another type would result in a
closed object type.
#class c = object (self) method m = (self : #c :> c) end;;
This expression has type < m : c; .. > but is here used with type c = < .. >
Self type cannot escape its class
This problem can sometimes be avoided by first defining the abbreviation,
using a class type:
#class type c0 = object method m : c0 end;;
class type c0 = object method m : c0 end
#class c : c0 = object (self) method m = (self : #c0 :> c0) end;;
class c : c0
It is also possible to use a virtual class. Inheriting from this class
simultaneously allows to enforce all methods of c to have the same
type as the methods of c0.
#class virtual c0 = object method virtual m : c0 end;;
class virtual c0 : object method virtual m : c0 end
#class c = object (self) inherit c0 method m = (self : #c0 :> c0) end;;
class c : object method m : c0 end
One could think of defining the type abbreviation directly:
#type c1 = <m : c1>;;
type c1 = < m : c1 >
However, the abbreviation #c0 cannot be defined directly in a similar
It can only be defined by a class or a classtyped definition.
(One reason is that # sharp abbreviations carry an implicit anonymous
variable .. that cannot be explicitly named).
Thus, the abbreviation #c0 should be expanded:
#class c = object (self) method m = (self : <m : c1; ..> as 'a :> c1) end;;
Already bound type parameter a
It is possible to write a version of class point without assignments
on the instance variables. The construct {< ... >} returns a copy of
``self'' (that is, the current object), possibly changing the value of
some instance variables.
#class functional_point y =
object
val x = y
method get_x = x
method move d = {< x = x + d >}
end;;
class functional_point :
int ->
object ('a) val x : int method get_x : int method move : int -> 'a end
#let p = new functional_point 7;;
val p : functional_point = <obj>
#p#get_x;;
- : int = 7
#(p#move 3)#get_x;;
- : int = 10
#p#get_x;;
- : int = 7
Note that the type abbreviation functional_point is recursive, which can
be seen in the class type of functional_point: the type of self is 'a
and 'a appears inside the type of the method move.
The above definition of functional_point is not equivalent
to the following:
#class bad_functional_point y =
object
val x = y
method get_x = x
method move d = new functional_point (x+d)
end;;
class bad_functional_point :
int ->
object
val x : int
method get_x : int
method move : int -> functional_point
end
#let p = new functional_point 7;;
val p : functional_point = <obj>
#p#get_x;;
- : int = 7
#(p#move 3)#get_x;;
- : int = 10
#p#get_x;;
- : int = 7
While objects of either class will behave the same, objects of their
subclasses will be different. In a subclass of the latter, the method
move will
keep returning an object of the parent class. On the contrary, in a
subclass of the former, the method move will return an object of the
subclass.
Functional update is often used in conjunction with binary methods
as illustrated in section 5.2.1.
Objects can also be cloned, whether they are functional or imperative.
The library function Oo.copy makes a shallow copy of an object. That is,
it returns an object that is equal to the previous one. The
instance variables have been copied but their contents are shared.
Assigning a new value to an instance variable of the copy (using a method
call) will not affect instance variables of the original, and conversely.
A deeper assignment (for example if the instance variable if a reference cell)
will of course affect both the original and the copy.
The type of Oo.copy is the following:
#Oo.copy;;
- : (< .. > as 'a) -> 'a = <fun>
The keyword as in that type binds the type variable 'a to
the object type < .. >. Therefore, Oo.copy takes an object with
any methods (represented by the ellipsis), and returns an object of
the same type. The type of Oo.copy is different from type < .. > -> < .. > as each ellipsis represents a different set of methods.
Ellipsis actually behaves as a type variable.
#let p = new point 5;;
val p : point = <obj>
#let q = Oo.copy p;;
val q : point = <obj>
#q#move 7; (p#get_x, q#get_x);;
- : int * int = 5, 12
In fact, Oo.copy p will behave as p#copy assuming that a public
method copy with body {< >} has been defined in the class of p.
Objects can be compared using the generic comparison functions = and <>.
Two objects are equal if and only if they are physically equal. In
particular, an object and its copy are not equal.
#let q = Oo.copy p;;
val q : point = <obj>
#p = q, p = p;;
- : bool * bool = false, true
Other generic comparissons such as (<, <=,...) can also be used on objects. The
relation < defines an unspecified but strict ordering on objets. The
ordering relationship between two objects is fixed once for all after the
two objects have been created and it is not affected by mutation of fields.
Cloning and override have a non empty intersection.
They are interchangeable when used within an object and without
overriding any field:
#class copy =
object
method copy = {< >}
end;;
class copy : object ('a) method copy : 'a end
#class copy =
object (self)
method copy = Oo.copy self
end;;
class copy : object ('a) method copy : 'a end
Only the override can be used to actually override fields, and
only the Oo.copy primitive can be used externally.
Cloning can also be used to provide facilities for saving and
restoring the state of objects.
#class backup =
object (self : 'mytype)
val mutable copy = None
method save = copy <- Some {< copy = None >}
method restore = match copy with Some x -> x | None -> self
end;;
class backup :
object ('a)
val mutable copy : 'a option
method restore : 'a
method save : unit
end
The above definition will only backup one level.
The backup facility can be added to any class using multiple inheritance.
#class ['a] backup_ref x = object inherit ['a] ref x inherit backup end;;
class ['a] backup_ref :
'a ->
object ('b)
val mutable copy : 'b option
val mutable x : 'a
method get : 'a
method restore : 'b
method save : unit
method set : 'a -> unit
end
#let rec get p n = if n = 0 then p # get else get (p # restore) (n-1);;
val get : (< get : 'b; restore : 'a; .. > as 'a) -> int -> 'b = <fun>
#let p = new backup_ref 0 in
p # save; p # set 1; p # save; p # set 2;
[get p 0; get p 1; get p 2; get p 3; get p 4];;
- : int list = [2; 1; 1; 1; 1]
A variant of backup could retain all copies. (We then add a method clear to
manually erase all copies.)
#class backup =
object (self : 'mytype)
val mutable copy = None
method save = copy <- Some {< >}
method restore = match copy with Some x -> x | None -> self
method clear = copy <- None
end;;
class backup :
object ('a)
val mutable copy : 'a option
method clear : unit
method restore : 'a
method save : unit
end
#class ['a] backup_ref x = object inherit ['a] ref x inherit backup end;;
class ['a] backup_ref :
'a ->
object ('b)
val mutable copy : 'b option
val mutable x : 'a
method clear : unit
method get : 'a
method restore : 'b
method save : unit
method set : 'a -> unit
end
#let p = new backup_ref 0 in
p # save; p # set 1; p # save; p # set 2;
[get p 0; get p 1; get p 2; get p 3; get p 4];;
- : int list = [2; 1; 0; 0; 0]
Recursive classes can be used to define objects whose types are
mutually recursive.
#class window =
object
val mutable top_widget = (None : widget option)
method top_widget = top_widget
end
and widget (w : window) =
object
val window = w
method window = window
end;;
class window :
object
val mutable top_widget : widget option
method top_widget : widget option
end
class widget :
window -> object val window : window method window : window end
Although their types are mutually recursive, the classes widget and
window are themselves independent.
A binary method is a method which takes an argument of the same type
as self. The class comparable below is a template for classes with a
binary method leq of type 'a -> bool where the type variable 'a
is bound to the type of self. Therefore, #comparable expands to < leq : 'a -> bool; .. > as 'a. We see here that the binder as also
allows to write recursive types.
#class virtual comparable =
object (_ : 'a)
method virtual leq : 'a -> bool
end;;
class virtual comparable : object ('a) method virtual leq : 'a -> bool end
We then define a subclass money of comparable. The class money
simply wraps floats as comparable objects. We will extend it below with
more operations. There is a type constraint on the class parameter x
as the primitive <= is a polymorphic comparison function in
Objective Caml. The inherit clause ensures that the type of objects
of this class is an instance of #comparable.
#class money (x : float) =
object
inherit comparable
val repr = x
method value = repr
method leq p = repr <= p#value
end;;
class money :
float ->
object ('a)
val repr : float
method leq : 'a -> bool
method value : float
end
Note that the type money1 is not a subtype of type
comparable, as the self type appears in contravariant position
in the type of method leq.
Indeed, an object m of class money has a method leq
that expects an argument of type money since it accesses
its value method. Considering m of type comparable would allow to
call method leq on m with an argument that does not have a method
value, which would be an error.
Similarly, the type money2 below is not a subtype of type money.
#class money2 x =
object
inherit money x
method times k = {< repr = k *. repr >}
end;;
class money2 :
float ->
object ('a)
val repr : float
method leq : 'a -> bool
method times : float -> 'a
method value : float
end
It is however possible to define functions that manipulate objects of
type either money or money2: the function min
will return the minimum of any two objects whose type unifies with
#comparable. The type of min is not the same as #comparable -> #comparable -> #comparable, as the abbreviation #comparable hides a
type variable (an ellipsis). Each occurrence of this abbreviation
generates a new variable.
#let min (x : #comparable) y =
if x#leq y then x else y;;
val min : (#comparable as 'a) -> 'a -> 'a = <fun>
This function can be applied to objects of type money
or money2.
#(min (new money 1.3) (new money 3.1))#value;;
- : float = 1.300000
#(min (new money2 5.0) (new money2 3.14))#value;;
- : float = 3.140000
More examples of binary methods can be found in sections
5.2.1 and 5.2.3.
Notice the use of functional update for method times.
Writing new money2 (k *. repr) instead of {< repr = k *. repr >}
would not behave well with inheritance: in a subclass money3 of money2
the times method would return an object of class money2 but not of class
money3 as would be expected.
The class money could naturally carry another binary method. Here is a
direct definition:
#class money x =
object (self : 'a)
val repr = x
method value = repr
method print = print_float repr
method times k = {< repr = k *. x >}
method leq (p : 'a) = repr <= p#value
method plus (p : 'a) = {< repr = x +. p#value >}
end;;
class money :
float ->
object ('a)
val repr : float
method leq : 'a -> bool
method plus : 'a -> 'a
method print : unit
method times : float -> 'a
method value : float
end
The above class money reveals a problem that often occurs with binary
methods. In order to interact with other objects of the same class, the
representation of money objects must be revealed, using a method such as
value. If we remove all binary methods (here plus and leq),
the representation can easily be hidden inside objects by removing the method
value as well. However, this is not possible as long as some binary
requires access to the representation on object of the same class but
different from self.
#class safe_money x =
object (self : 'a)
val repr = x
method print = print_float repr
method times k = {< repr = k *. x >}
end;;
class safe_money :
float ->
object ('a)
val repr : float
method print : unit
method times : float -> 'a
end
Here, the representation of the object is known only to a particular object.
To make it available to other objects of the same class, we are forced to
make it available to the whole world. However we can easily restrict the
visibility of the representation using the module system.
#module type MONEY =
sig
type t
class c : float ->
object ('a)
val repr : t
method value : t
method print : unit
method times : float -> 'a
method leq : 'a -> bool
method plus : 'a -> 'a
end
end;;
module Euro : MONEY =
struct
type t = float
class c x =
object (self : 'a)
val repr = x
method value = repr
method print = print_float repr
method times k = {< repr = k *. x >}
method leq (p : 'a) = repr <= p#value
method plus (p : 'a) = {< repr = x +. p#value >}
end
end;;
Another example of friend functions may be found in section
5.2.3. These examples occur when a group of objects (here
objects of the same class) and functions should see each others internal
representation, while their representation should be hidden from the
outside. The solution is always to define all friends in the same module,
give access to the representation and use a signature constraint to make the
representation abstract outside of the module.