Le principe est le même, on enrichi notre type (ici notre classe), avec des informations qui n'ont pas de rapport avec les données contenues, mais qui permettent d'indiquer au compilateur ce que l'on autorise ou non. Bizarrement, je vois rarement de code java mettre en œuvre cette pratique, qui me paraît pourtant être une manière presque naturelle...
Je suis peut-être un peu naïf, mais dans les langages objet, l'idiome naturel pour arriver à cette fonctionnalité c'est d'utiliser l'héritage (à moins que je n'aie pas compris ce qu'on cherchait à faire), exemple en Java :
abstract class A {
/* vraies fonctionnalités */
}
final class B extends A { /* rien de particulier */ }
final class C extends A { /* rien de particulier */ }
Clairement, on peut avoir des méthodes acceptant B mais pas C ou vice versa.
B et C ne jouent que le rôle de marqueurs (comme les types fantômes, non ?) et A, étant abstract, ne peut pas être instancié directement tel quel (tout comme les types dépendants en OCaml ou ailleurs).
Bien sûr on peut aussi faire avec des génériques, mais ça me paraît moins naturel d'introduire un paramètre de type qui ne sera jamais utilisé à l'intérieur de la définition du type.
Plus haut, dans le journal, je vois la mention "autrement qu'en faisant des classes". Je ne comprends pas cette remarque. Les classes sont la façon normale, parfois la seule, de définir la structure d'un type dans un langage objet (on pourrait remplacer "classe" par "interface", mais j'imagine que ça ne change rien à la remarque). On ne peut pas reprocher à un langage non-fonctionnel de ne pas disposer de syntaxes de définition de type à la façon "langage fonctionnel".
[^] # Re: Type fantôme
Posté par Aldoo . En réponse au journal Une petite histoire d'utilisation type fort dans Ocaml. Évalué à 2.
Je suis peut-être un peu naïf, mais dans les langages objet, l'idiome naturel pour arriver à cette fonctionnalité c'est d'utiliser l'héritage (à moins que je n'aie pas compris ce qu'on cherchait à faire), exemple en Java :
Clairement, on peut avoir des méthodes acceptant B mais pas C ou vice versa.
B et C ne jouent que le rôle de marqueurs (comme les types fantômes, non ?) et A, étant abstract, ne peut pas être instancié directement tel quel (tout comme les types dépendants en OCaml ou ailleurs).
Bien sûr on peut aussi faire avec des génériques, mais ça me paraît moins naturel d'introduire un paramètre de type qui ne sera jamais utilisé à l'intérieur de la définition du type.
Plus haut, dans le journal, je vois la mention "autrement qu'en faisant des classes". Je ne comprends pas cette remarque. Les classes sont la façon normale, parfois la seule, de définir la structure d'un type dans un langage objet (on pourrait remplacer "classe" par "interface", mais j'imagine que ça ne change rien à la remarque). On ne peut pas reprocher à un langage non-fonctionnel de ne pas disposer de syntaxes de définition de type à la façon "langage fonctionnel".