Bonjour,
La notation n'est pas très heureuse mais l'idée, c'est qu'il faut
utiliser la méthode "proj_i" de l'objet que l'on analyse pour obtenir
sa i-ème composante et la confronter ensuite au motif p_i.
Par contre, effectivement, il manquait une hypothèse dans cette règle
: si le test de sous-typage entre le type exact de l'objet et le type
t du motif a réussi, on appelle la méthode "unapply" de l'objet qui
produit un n-uplet "o_t". C'est la méthode "proj_i" de ce n-uplet que
l'on va appeler in fine.
J'ai mis à jour le sujet pour corriger ce problème.
Pour comprendre comment cela fonctionne, essayez déjà de comprendre ce
qui se passe dans cet exemple :
object test {
class List
class Nil extends List
class Cons (x : predefined.Int, l : List) extends List {
def hd = x
def tl = l
(* Ici, on définit la méthode "unapply" pour dire qu'un objet de type Cons
peut être vu comme une paire. *)
def unapply = (x, l)
}
object len {
def get (x : List) = x match {
case Nil => 0
case Cons (_, l) =>
(* Pour déterminer ce que vaut "l", l'interprète a fait :
(x.unapply ()).proj2 (). *)
len.get (l) + 1
}
}
val n = len.get (new Cons (1, new Cons (2, new Nil)))
}
--
Yann Régis-Gianas
New email :
y...@pps.univ-paris-diderot.fr
2012/5/30 Isabelle Richard <
isabelle...@gmail.com>: