La thèse de Jim O Coplien a l’avantage d’être en libre accès, après, cela peut valoir le coup de citer le livre qui en a été tiré: "Multiparadigm Design in C++" (IIRC)
Tous le laïus sur dispatch vs binding me dit quelque chose. J’ai l’impression de l’avoir déjà lu quelque part. Je ne sais plus si j’ai déjà lu cet article ou s’il y a réutilisation de choses d’ailleurs.
Je n’aurai pas dit que l’émulation du dispatch multiple était facile. Les visiteurs, c’est tordu, et les autres techniques sont loin d’être triviales. Après, le dispatch simple est un plaie qui impacte beaucoup de langages plus ou moins vaguement OO, et cela se voit rien qu’au choix de syntaxe. À partir du moment où l’on a un o.m(b), au lieu d’un f(a,b) ou d’un (f a b), on s’oriente automatiquement vers un dispatch simple.
On n’appelle pas une méthode depuis une instance de classe, mais sur. Le depuis laisse sous-entendre que ce n’est que depuis d’autres méthodes d’une même classe que l’on peut appeler celles d’une classe.
Je ne dirai pas que le visiteur est apparu pour résoudre le problème. Je trouve plutôt qu’il a été détourné pour résoudre ce problème. (Bon je n’ai pas mon GoF sur moi, je ne sais plus comment s’était formulé dedans). Le visiteur est orienté pour résoudre des doubles dispatchs asymétriques: petites hiérarchie finie de classes visitables, beaucoup de classes (nombre inconnu à l’avance) pouvant visiter. L’exemple classique des collisions dans les jeux de type asteroid est lui totalement symétrique – même si le nombre d’éléments est assez limité.
Dans les codes, je vois des pointeurs. Cela veut dire que l’objet peut être nul ? Si non, alors c’est une référence qu’il faut.
