En gros plutôt que dire: Ma méthode doit recevoir une instance du type X
Tu dis: Ma méthode doit recevoir un objet implémentant une méthode coin()
C'est exactement l'analyse que fait le compilateur OCaml lorsqu'il lit quelque chose comme ça:
#letsendx=x#send;;valsend:<send:'a;..>->'a=<fun>
Après évaluation send est une fonction acceptant tout objet admettant une méthode send et appelant ladite méthode desuss: c'est exactement ce que tu dis.
Dans les archives de la mailing list de OCaml j'ai retrouvé ça:
Re: Smells like duck-typing
--8<--
I am going for the no-inheritance object solution: [...] it allows code reuse thanks to OCaml's structural subtyping feature (the "duck" in this thread's title).
Les gens intervenant sur la liste sont certainement aussi peu manches que ceux de lambdathe-ultimate.org et apparemment personne n'a crié au scandale en voyant que quelque'un prétendait assimiler le duck typing au typage structurel.
Et pour l'instant aucun des arguments ici ne permet de vraiment faire la différence. Qu'est-ce que peut faire le duck-typing que ne permet pas le typage structurel?
[^] # Re: Duck typing
Posté par Michaël (site web personnel) . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 3.
C'est exactement l'analyse que fait le compilateur OCaml lorsqu'il lit quelque chose comme ça:
Après évaluation
sendest une fonction acceptant tout objet admettant une méthodesendet appelant ladite méthode desuss: c'est exactement ce que tu dis.Dans les archives de la mailing list de OCaml j'ai retrouvé ça:
Dario wrote:
Les gens intervenant sur la liste sont certainement aussi peu manches que ceux de lambdathe-ultimate.org et apparemment personne n'a crié au scandale en voyant que quelque'un prétendait assimiler le duck typing au typage structurel.
Et pour l'instant aucun des arguments ici ne permet de vraiment faire la différence. Qu'est-ce que peut faire le duck-typing que ne permet pas le typage structurel?