Au risque de me répéter :) A partir du moment où tu fais du duck typing, même en statique, tu n'as plus de contrôle de type.
Il n'y a plus de hiérarchie de types. Donc plus de vérification à la compilation... ce qui rend le typage statique caduque pour ce cas, alourdit le code et permet difficilement de concilier les 2 approches.
Ce n'est pas pour rien que Go ne supporte que le duck typing, en s'appuyant sur une forme de composition sans le moindre héritage d'implémentation.
Avec Python, on concilie le duck typing avec l'héritage multiple, ce qui d'ailleurs permet de se passer de la généricité.
Par contre, j'attends l'exemple dans un langage statiquement typé orienté objet (donc pas le Go) qui permet de se passer de l'héritage du type racine et du casting à posteriori.
Un truc quasi-quotidien dans les langages dynamiques.
[^] # Re: Performance
Posté par El Titi . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 0.
Au risque de me répéter :) A partir du moment où tu fais du duck typing, même en statique, tu n'as plus de contrôle de type.
Il n'y a plus de hiérarchie de types. Donc plus de vérification à la compilation... ce qui rend le typage statique caduque pour ce cas, alourdit le code et permet difficilement de concilier les 2 approches.
Ce n'est pas pour rien que Go ne supporte que le duck typing, en s'appuyant sur une forme de composition sans le moindre héritage d'implémentation.
Avec Python, on concilie le duck typing avec l'héritage multiple, ce qui d'ailleurs permet de se passer de la généricité.
Par contre, j'attends l'exemple dans un langage statiquement typé orienté objet (donc pas le Go) qui permet de se passer de l'héritage du type racine et du casting à posteriori.
Un truc quasi-quotidien dans les langages dynamiques.