Types et généricité
L'intérêt de la programmation par objet vient d'une part de la
modélisation d'un problème par les relations d'agrégation et
d'héritage, mais aussi de la possibilité de réutilisation et de
modification de comportement des classes. L'extension objet d'Objective CAML
doit de surcroît conserver les propriétés de typage statique du
langage.
Les classes abstraites permettent de factoriser du code mais
aussi de regrouper dans un même << protocole de communication >> leurs
sous-classes : une classe abstraite fixe les noms et types des
messages que pourront recevoir les instances de ses
héritières. Cette dernière notion sera encore plus appréciée avec
l'héritage multiple.
La notion de type objet ouvert ou, plus simplement, de
type ouvert, définissant les méthodes requises,
autorise la manipulation d'instances par des fonctions génériques.
Cependant, il faudra parfois préciser des contraintes de
type. Ce sera indispensable avec les classes paramétrées qui
reprennent la généricité du polymorphisme paramétrique dans le cadre
des classes. Ce dernier trait de la couche objet d'Objective CAML lui permet
d'être vraiment générique.
Classes et méthodes abstraites
Les classes abstraites sont des classes dont certaines méthodes sont
déclarées mais ne possèdent pas de corps. Ces méthodes sont
alors dites abstraites. Il n'est pas possible d'instancier une classe
abstraite : new est interdit. On utilise le mot clé
virtual pour signifier l'abstraction d'une classe ou d'une
méthode.
Syntaxe
class virtual nom =
object ...end
Une classe doit impérativement être déclarée abstraite dès
lors que l'une de ses méthodes l'est. On déclare une méthode
abstraite en donnant uniquement son type attendu.
Syntaxe
method virtual nom : type
Lorsqu'une une sous-classe d'une classe abstraite redéfinit toutes
les méthodes abstraites de son ancêtre, alors elle peut devenir
concrète, sinon elle doit elle aussi être déclarée abstraite.
Nous voulons construire un ensemble d'objets affichables disposant
tous d'une méthode print qui affichera le contenu de
l'objet traduit en chaîne de caractères. Ces objets
devront donc posséder une méthode
to_string.
Nous définissons à cet effet la classe printable.
Suivant la nature des objets considérés, la chaîne à
construire pourra varier. La méthode to_string sera donc
abstraite dans la déclaration de printable.
Du coup, cette classe est également abstraite.
# class virtual printable () =
object(self)
method virtual to_string : unit -> string
method print () = print_string (self#to_string())
end ;;
class virtual printable :
unit ->
object
method print : unit -> unit
method virtual to_string : unit -> string
end
Notons que le caractère abstrait de la classe et de sa méthode
to_string est manifeste dans le type obtenu.
À partir de cette classe on cherche à définir la hiérarchie de
classes de la figure 15.4.
Figure 15.4 : relations entre classes d'objets affichables
On redéfinit facilement les classes point,
colored_point et picture. Il suffit d'ajouter dans
leurs déclarations la ligne inherit printable () pour
les doter par héritage de la méthode print.
# let p = new point (1,1) in p#print() ;;
( 1, 1)- : unit = ()
# let pc = new colored_point (2,2) "bleu" in pc#print() ;;
( 2, 2) de couleur bleu- : unit = ()
# let t = new picture 3 in t#add (new point (1,1)) ;
t#add (new point (3,2)) ;
t#add (new point (1,4)) ;
t#print() ;;
[ ( 1, 1) ( 3, 2) ( 1, 4)]- : unit = ()
La sous-classe rectangle suivante hérite de
printable et définit la méthode to_string.
Les variables d'instance llc et ruc désignent respectivement
le point en bas à gauche et le point en haut à droite du rectangle.
# class rectangle (p1,p2) =
object
inherit printable ()
val mutable llc = (p1 : point)
val mutable ruc = (p2 : point)
method to_string () = "[" ^ p1#to_string() ^ "," ^ p2#to_string() ^ "]"
end ;;
class rectangle :
point * point ->
object
val mutable llc : point
val mutable ruc : point
method print : unit -> unit
method to_string : unit -> string
end
La classe rectangle hérite de la classe abstraite
printable, et donc récupère la méthode
print. Elle possède deux variables d'instance
point : les coins inférieur gauche (llc) et
supérieur droit (ruc). Sa méthode to_string envoie
le message to_string à ses variables d'instance point.
# let r = new rectangle (new point (2,3), new point (4,5));;
val r : rectangle = <obj>
# r#print();;
[( 2, 3),( 4, 5)]- : unit = ()
Classes, types et objets
Rappelons que le type d'un objet est le type de ses méthodes. Par exemple le
type
point, inféré lors de la déclaration de la classe
point, est une abréviation du type :
point =
< distance : unit -> float; get_x : int; get_y : int;
moveto : int * int -> unit; rmoveto : int * int -> unit;
to_string : unit -> string >
C'est un type objet fermé. C'est-à-dire que la totalité
des méthodes et des types associés qui le composent est déterminée ; il
n'y en a pas d'autre.
Le mécanisme d'inférence de types, lors d'une déclaration de
classe, calcule le type fermé associé à cette classe.
Types ouverts
L'envoi d'un message à un objet fait partie intégrante du
langage, on peut donc définir une fonction envoyant un message
quelconque à un objet dont le type est non précisé.
# let f x = x#get_x ;;
val f : < get_x : 'a; .. > -> 'a = <fun>
Le type inféré pour l'argument de f est un type objet,
puisque l'on envoie un message à x, mais ce type objet est
ouvert. Le paramètre x de la fonction f doit
au moins posséder une méthode get_x. Comme le résultat de
l'envoi de ce message n'est pas utilisé dans la fonction f,
son type est le plus général possible (c'est-à-dire une variable de
type 'a). Le mécanisme d'inférence de types laisse donc la
possibilité d'utiliser la fonction f avec n'importe quel
objet possédant une méthode get_x. L'ouverture du type de
x est signifiée par les deux points (..) à la fin du type
< get_x : 'a; .. >
# f (new point(2,3)) ;;
- : int = 2
# f (new colored_point(2,3) "vert émeraude") ;;
- : int = 2
# class c () =
object
method get_x = "J'ai une méthode get_x"
end ;;
class c : unit -> object method get_x : string end
# f (new c ()) ;;
- : string = "J'ai une m\233thode get_x"
L'inférence de types pour les classes peut engendrer des types ouverts,
en particulier pour les valeurs initiales de construction des instances.
L'exemple suivant construit une classe couple,
dont les valeurs initiales a
et b possèdent une méthode to_string.
# class couple (a,b) =
object
val p0 = a
val p1 = b
method to_string() = p0#to_string() ^ p1#to_string()
method copy () = new couple (p0,p1)
end ;;
class couple :
(< to_string : unit -> string; .. > as 'a) *
(< to_string : unit -> string; .. > as 'b) ->
object
val p0 : 'a
val p1 : 'b
method copy : unit -> couple
method to_string : unit -> string
end
Les types de a et b sont deux types ouverts possédant
la méthode to_string. On note que ces deux types sont
considérés comme différents. Ils sont notés respectivement comme
as 'a et as 'b. Les variables de
types 'a et 'b sont contraintes par le type ouvert
engendré.
On désigne le type ouvert construit à partir d'un type fermé
obj_type en utilisant le symbole dièse :
Syntaxe
#obj_type
Le type obtenu contient toutes les méthodes du type
obj_type et se termine par deux points.
Contrainte de type
Nous avons montré au chapitre sur la programmation fonctionnelle (voir
page ??) comment contraindre une expression à
posséder un type plus précis que celui engendré par l'inférence. Les
types objet, fermés ou ouverts, peuvent être utilisés pour effectuer
de telles contraintes. On peut vouloir a priori ouvrir le type
d'un objet défini pour lui appliquer une méthode à venir. On utilise
alors une contrainte de type objet ouvert :
Syntaxe
(nom:#type)
Ce qui permet d'écrire :
# let g (x : #point) = x#amess;;
val g :
< amess : 'a; distance : unit -> float; get_x : int; get_y : int;
moveto : int * int -> unit; print : unit -> unit;
rmoveto : int * int -> unit; to_string : unit -> string; .. > ->
'a = <fun>
La contrainte de type avec #point force x
à avoir au moins toutes les méthodes de point, et
l'envoi du message amess ajoute une méthode au type du
paramètre x.
Comme dans le reste du langage, l'extension objet d'Objective CAML offre un
typage statique obtenu par inférence. Lorsque ce mécanisme ne
dispose pas de l'information suffisante pour déterminer le type
d'une expression, il lui assigne une variable de type. Nous venons de
voir que ce phénomène est aussi valable pour le typage des
objets. Il peut engendrer parfois des situations de blocage que
l'utilisateur devra résoudre en donnant explicitement des
informations de type.
# class a_point p0 =
object
val p = p0
method to_string() = p#to_string()
end ;;
Characters 6-89:
Some type variables are unbound in this type:
class a_point :
(< to_string : unit -> 'b; .. > as 'a) ->
object val p : 'a method to_string : unit -> 'b end
The method to_string has type unit -> 'a where 'a is unbound
On sort de ce blocage en précisant que le paramètre p0
est de type #point.
# class a_point (p0 : #point) =
object
val p = p0
method to_string() = p#to_string()
end ;;
class a_point :
(#point as 'a) -> object val p : 'a method to_string : unit -> string end
Pour éviter de placer les contraintes de type à plusieurs endroits dans la
déclaration d'une classe, on utilise la syntaxe suivante :
Syntaxe
constraint type1 = type2
L'exemple précédent peut s'écrire en indiquant que le paramètre
p0 est de type 'a, puis en posant une contrainte
de type sur la variable 'a.
# class a_point (p0 : 'a) =
object
constraint 'a = #point
val p = p0
method to_string() = p#to_string()
end ;;
class a_point :
(#point as 'a) -> object val p : 'a method to_string : unit -> string end
Plusieurs contraintes de type peuvent être posées dans une déclaration de classe.
Warning
Un type ouvert ne peut pas apparaître comme type d'une méthode.
Cette contrainte forte provient du fait qu'un type ouvert contient une
variable de type non encore instanciée provenant de la suite du
type. Comme on ne peut avoir une variable de type libre dans une
déclaration de type, une méthode contenant un tel type est rejetée par
l'inférence de types.
# class b_point p0 =
object
inherit a_point p0
method get = p
end ;;
Characters 6-77:
Some type variables are unbound in this type:
class b_point :
(#point as 'a) ->
object val p : 'a method get : 'a method to_string : unit -> string end
The method get has type #point where .. is unbound
Le type de get est en fait, à cause de la contrainte
constraint 'a = #point, le type ouvert
#point. Celui-ci contient la variable de type libre dénotée
par le double point (..) ce qui n'est pas autorisé.
Héritage et type de self
Il existe une exception pour l'apparition d'une variable de type dans
le type des méthodes. Il s'agit du cas où une variable désigne le
type de l'objet lui-même (self). Prenons l'exemple d'une
méthode d'égalité qui teste si un point est égal à un autre.
# class point_eq (x,y) =
object (self : 'a)
inherit point (x,y)
method eq (p:'a) = (self#get_x = p#get_x) && (self#get_y = p#get_y)
end ;;
class point_eq :
int * int ->
object ('a)
val mutable x : int
val mutable y : int
method distance : unit -> float
method eq : 'a -> bool
method get_x : int
method get_y : int
method moveto : int * int -> unit
method print : unit -> unit
method rmoveto : int * int -> unit
method to_string : unit -> string
end
Le type de la méthode eq est 'a -> bool, mais la
variable de type désigne le type de l'instance lors de sa
construction.
On peut hériter de la classe point_eq et redéfinir
la méthode eq dont le type est toujours paramétré par
le type de l'instance.
# class colored_point_eq (xc,yc) c =
object (self : 'a)
inherit point_eq (xc,yc) as super
val c = (c:string)
method get_c = c
method eq (pc : 'a) = (self#get_x = pc#get_x) && (self#get_y = pc#get_y)
&& (self#get_c = pc#get_c)
end ;;
class colored_point_eq :
int * int ->
string ->
object ('a)
val c : string
val mutable x : int
val mutable y : int
method distance : unit -> float
method eq : 'a -> bool
method get_c : string
method get_x : int
method get_y : int
method moveto : int * int -> unit
method print : unit -> unit
method rmoveto : int * int -> unit
method to_string : unit -> string
end
La méthode eq, de la classe colored_point_eq, est
toujours du type 'a -> bool, mais, cette fois, la variable
'a désigne le type d'une instance de la classe
colored_point_eq. La définition de eq de la classe
colored_point_eq masque celle héritée. Les méthodes
contenant le type de l'instance dans leur type sont appelées méthodes
binaires. Elles créeront des limitations à la relation de sous-typage
décrite à la page ??.
Héritage multiple
L'héritage multiple permet d'hériter des champs de données et des
méthodes de plusieurs classes. En cas de noms de champs ou de
méthodes identiques, seulement la dernière déclaration, dans l'ordre
des déclarations d'héritages, sera conservée. Néanmoins, on peut
référencer une méthode d'une des classes ancêtres en associant des
noms différents à chaque classe dont on hérite. Cela n'est pas
valable pour les variables d'instance. Si une classe héritée masque
une variable d'instance d'une classe précédemment héritée, cette
dernière variable n'est plus accessible directement. Les différentes
classes héritées n'ont pas forcément de lien d'héritage entre
elles. L'intérêt de l'héritage multiple est d'augmenter la
réutilisabilité des classes.
On définit la classe abstraite geometric_object qui
déclare deux méthodes virtuelles compute_area et
compute_circ pour le calcul de la surface et du
périmètre.
# class virtual geometric_object () =
object
method virtual compute_area : unit -> float
method virtual compute_circ : unit -> float
end;;
On redéfinit alors la classe rectangle de la manière
suivante :
# class rectangle_bis ((p1,p2) :'a) =
object
constraint 'a = point * point
inherit printable ()
inherit geometric_object ()
val mutable llc = p1
val mutable ruc = p2
method to_string () =
"["^p1#to_string()^","^p2#to_string()^"]"
method compute_area() =
float ( abs(ruc#get_x - llc#get_x) * abs(ruc#get_y - llc#get_y))
method compute_circ() =
float ( (abs(ruc#get_x - llc#get_x) + abs(ruc#get_y - llc#get_y)) * 2)
end;;
class rectangle_bis :
point * point ->
object
val mutable llc : point
val mutable ruc : point
method compute_area : unit -> float
method compute_circ : unit -> float
method print : unit -> unit
method to_string : unit -> string
end
Cette implantation de classes respecte le graphe d'héritage de la figure 15.5.
Figure 15.5 : héritage multiple
Pour ne pas avoir à réécrire la méthode de la classe
rectangle, on peut hériter directement de rectangle
comme le montre le schéma de la figure 15.6.
Figure 15.6 : héritage multiple (suite)
Dans ce cas là, seules les méthodes abstraites de la classe
abstraite geometric_object doivent être définies dans
rectangle_ter.
# class rectangle_ter (p2 :'a) =
object
constraint 'a = point * point
inherit rectangle p2
inherit geometric_object ()
method compute_area() =
float ( abs(ruc#get_x - llc#get_x) * abs(ruc#get_y - llc#get_y))
method compute_circ() =
float ( (abs(ruc#get_x - llc#get_x) + abs(ruc#get_y - llc#get_y)) * 2)
end;;
Toujours dans la même veine, les développements de la hiérarchie
printable et geometric_object auraient
pu être séparés jusqu'au moment où il devenait utile d'avoir une
classe possédant les deux comportements. Le schéma de la figure
15.7 montre les relations ainsi définies.
Figure 15.7 : héritage multiple (fin)
Si on suppose que les classes printable_rect et
geometric_rect définissent des variables d'instance pour
les coins d'un rectangle, on se retrouve dans la classe
rectangle avec quatre points (deux par coin).
class rectangle_quarte (p1,p2) =
inherit printable_rect (p1,p2) as super_print
inherit geometric_rect (p1,p2) as super_geo
end;;
Dans le cas où des méthodes de même type existent dans les deux
classes ..._rect, alors seule la dernière est
visible. Néanmoins, grâce au nommage des classes ancêtres
(super_...), il est toujours possible d'invoquer une
méthode de l'une ou l'autre des ancêtres.
L'héritage multiple permet donc une factorisation du code en
intégrant les méthodes déjà écrites de différentes classes ancêtres
pour construire une nouvelle entité. Le prix à payer est la taille
des objets construits plus gros que nécessaire : duplication de
champs, héritage de champs inutiles à une application donnée, etc...
De plus, en cas de duplication, comme dans notre dernier exemple, il
faut établir manuellement la communication entre ces champs (mise à
jour, etc...). Dans le dernier exemple sur la classe
rectangle, on obtient les variables d'instance de la classe
rectangle_graph et rectangle_geo. Si l'une de ces
classes possède une méthode qui modifie ces variables (comme un
facteur d'échelle) alors il est nécessaire de répercuter ces
modifications aux variables héritées de l'autre classe. Cette trop
lourde communication entre variables d'instance héritées souligne
souvent une mauvaise modélisation du problème posé.
Classes paramétrées
Les classes paramétrées permettent d'utiliser le polymorphisme
paramétrique d'Objective CAML dans les classes. Une déclaration de classe
peut être paramétrée par des variables de type, comme dans une
déclaration de types d'Objective CAML. Cela offre de nouvelles
possibilités de généricité, pour la réutilisation du code,
et s'intègre dans le typage à la ML quand l'inférence de types
produit des types paramétrés.
La syntaxe diffère légèrement de la déclaration de types paramétrés,
les paramètres de type sont entre crochets.
Syntaxe
class ['a, 'b, ...]
nom = object ...end
Néanmoins le type Objective CAML est noté comme à l'habitude :
('a,'b,...) nom.
Par exemple, si l'on désire construire une classe pair pour
décrire les paires, une solution naïve consiste à poser :
# class pair x0 y0 =
object
val x = x0
val y = y0
method fst = x
method snd = y
end ;;
Characters 6-106:
Some type variables are unbound in this type:
class pair :
'a ->
'b -> object val x : 'a val y : 'b method fst : 'a method snd : 'b end
The method fst has type 'a where 'a is unbound
On retrouve l'erreur de typage évoquée à la définition de la classe
a_point (page ??). Le
message d'erreur indique que la variable de type 'a assignée
au paramètre x0 (et donc à x et
fst) n'est pas liée.
Pour obtenir un typage correct, comme
dans le cas des types paramétrés, il faut paramétrer la classe
pair avec deux variables de type et forcer le type des
paramètres de construction x0 et y0 :
# class ['a,'b] pair (x0:'a) (y0:'b) =
object
val x = x0
val y = y0
method fst = x
method snd = y
end ;;
class ['a, 'b] pair :
'a ->
'b -> object val x : 'a val y : 'b method fst : 'a method snd : 'b end
L'affichage de l'inférence de types indique une interface de classe
paramétrée par les variables de type 'a et 'b.
Quand on construit une valeur d'une classe paramétrée, les paramètres
de type sont instanciés par les types des paramètres de construction :
# let p = new pair 2 'X';;
val p : (int, char) pair = <obj>
# p#fst;;
- : int = 2
# let q = new pair 3.12 true;;
val q : (float, bool) pair = <obj>
# q#snd;;
- : bool = true
Remarque
Dans les déclarations de classe, les paramètres de type sont notés
entre crochets, alors qu'au niveau de l'affichage des types, ils se
retrouvent entre parenthèses.
Héritage de classes paramétrées
L'héritage d'une classe paramétrée doit indiquer les paramètres de
cette classe. On définit une classe acc_pair, qui hérite de
('a,'b) pair et ajoute deux méthodes d'accès aux champs ,
get1 et get2,
# class ['a,'b] acc_pair (x0 : 'a) (y0 : 'b) =
object
inherit ['a,'b] pair x0 y0
method get1 z = if x = z then y else raise Not_found
method get2 z = if y = z then x else raise Not_found
end;;
class ['a, 'b] acc_pair :
'a ->
'b ->
object
val x : 'a
val y : 'b
method fst : 'a
method get1 : 'a -> 'b
method get2 : 'b -> 'a
method snd : 'b
end
# let p = new acc_pair 3 true;;
val p : (int, bool) acc_pair = <obj>
# p#get1 3;;
- : bool = true
On peut préciser les paramètres de type de la classe paramétrée héritée,
par exemple pour une paire de points.
# class pair_point (p1,p2) =
object
inherit [point,point] pair p1 p2
end;;
class pair_point :
point * point ->
object
val x : point
val y : point
method fst : point
method snd : point
end
La classe pair_point n'a plus besoin de paramètres de type,
car les paramètres 'a et 'b sont complètement
déterminés.
Pour construire des paires d'objets affichables, c'est-à-dire
possédant une méthode print, on réutilise la classe abstraite
printable (voir page ??), puis
on définit la classe printable_pair qui hérite de
pair.
# class printable_pair (x0 ) (y0 ) =
object
inherit [printable, printable] acc_pair x0 y0
method print () = x#print(); y#print ()
end;;
Cette implantation permet effectivement de construire des paires
d'instances de printable, mais ne peut pas être utilisée pour
des objets d'une autre classe et possédant une méthode print.
Un premier essai consiste à ouvrir le type printable
utilisé comme paramètre de type de acc_pair :
# class printable_pair (x0 ) (y0 ) =
object
inherit [ #printable, #printable ] acc_pair x0 y0
method print () = x#print(); y#print ()
end;;
Characters 6-149:
Some type variables are unbound in this type:
class printable_pair :
(#printable as 'a) ->
(#printable as 'b) ->
object
val x : 'a
val y : 'b
method fst : 'a
method get1 : 'a -> 'b
method get2 : 'b -> 'a
method print : unit -> unit
method snd : 'b
end
The method fst has type #printable where .. is unbound
Cet essai échoue car les méthodes fst et snd contiennent
un type ouvert.
Nous allons donc conserver les paramètres de type de la classe, tout en les
contraignant au type ouvert #printable.
# class ['a,'b] printable_pair (x0 ) (y0 ) =
object
constraint 'a = #printable
constraint 'b = #printable
inherit ['a,'b] acc_pair x0 y0
method print () = x#print(); y#print ()
end;;
class ['a, 'b] printable_pair :
'a ->
'b ->
object
constraint 'a = #printable
constraint 'b = #printable
val x : 'a
val y : 'b
method fst : 'a
method get1 : 'a -> 'b
method get2 : 'b -> 'a
method print : unit -> unit
method snd : 'b
end
On construit alors une paire affichable contenant un point et un
point coloré.
# let pp = new printable_pair
(new point (1,2)) (new colored_point (3,4) "vert");;
val pp : (point, colored_point) printable_pair = <obj>
# pp#print();;
( 1, 2)( 3, 4) de couleur vert- : unit = ()
Classes paramétrées et typage
Une classe paramétrée est, du point de vue des types, un type paramétré.
Une valeur d'un tel type peut alors contenir des variables de type faibles.
# let r = new pair [] [];;
val r : ('_a list, '_b list) pair = <obj>
# r#fst;;
- : '_a list = []
# r#fst = [1;2];;
- : bool = false
# r;;
- : (int list, '_a list) pair = <obj>
Une classe paramétrée est aussi vue comme un type objet fermé,
donc rien n'empêche
de l'utiliser aussi comme type ouvert avec la notation dièse.
# let compare_rien ( x : ('a, 'a) #pair) =
if x#fst = x#fst then x#mess else x#mess2;;
val compare_rien : < fst : 'a; mess : 'b; mess2 : 'b; snd : 'a; .. > -> 'b =
<fun>
Ce qui nous amène à pouvoir construire des types paramétrés contenant des variables
de type faibles, tout en étant des types objet ouverts.
# let jolitype x ( y : ('a, 'a) #pair) = if x = y#fst then y else y;;
val jolitype : 'a -> (('a, 'a) #pair as 'b) -> 'b = <fun>
Si on applique cette fonction à un seul paramètre, on obtient une
fermeture dont les variables de type deviennent faibles. Un type
ouvert, comme #pair, contient encore une partie à instancier
représentée par les deux points (..). En cela un type ouvert est un
paramètre de type dont une partie est déjà connue. Lors de
l'affaiblissement d'un tel type suite à une application partielle,
l'afficheur précise que la variable de type représentant ce type
ouvert est affaiblie. La notation est alors _#pair.
# let g = jolitype 3;;
val g : ((int, int) _#pair as 'a) -> 'a = <fun>
Si maintenant on applique la fonction g à une paire, on
modifie son type faible.
# g (new acc_pair 2 3);;
- : (int, int) acc_pair = <obj>
# g;;
- : (int, int) acc_pair -> (int, int) acc_pair = <fun>
On ne peut plus alors utiliser g sur des paires simples.
# g (new pair 1 1);;
Characters 4-16:
This expression has type (int, int) pair = < fst : int; snd : int >
but is here used with type
(int, int) acc_pair =
< fst : int; get1 : int -> int; get2 : int -> int; snd : int >
Only the second object type has a method get1
Enfin comme les paramètres de la classe paramétrée peuvent eux aussi
s'affaiblir, on obtient l'exemple suivant.
# let h = jolitype [];;
val h : (('_b list, '_b list) _#pair as 'a) -> 'a = <fun>
# let h2 = h (new pair [] [1;2]);;
val h2 : (int list, int list) pair = <obj>
# h;;
- : (int list, int list) pair -> (int list, int list) pair = <fun>
Le type du paramètre de h n'est plus ouvert. L'application
suivante n'est pas typable car l'argument n'est pas de type pair.
# h (new acc_pair [] [4;5]);;
Characters 4-25:
This expression has type
('a list, int list) acc_pair =
< fst : 'a list; get1 : 'a list -> int list; get2 : int list -> 'a list;
snd : int list >
but is here used with type
(int list, int list) pair = < fst : int list; snd : int list >
Only the first object type has a method get1
Remarque
Les classes paramétrées d'Objective CAML sont absolument nécessaires dès que
l'on manipule des méthodes dont le type comporte une variable de type
autre que le type de self.
