Cependant le type de l'objet va changer (i.e. ce sera celui du Proxy) et donc il faudra que tes fonctions acceptants l'objet initial puisse accepter le nouveau. Si tes fonctions sont initialement "templatées", c'est faisable, sinon, c'est mort. Point de plus pour le langage dynamique.
C'est pas le dynamisme qui joue là, mais le stypage structurel/duck typing.
Le type d'une fonction étant défini juste par ses arguments / valeur de retour, si ton proxy à la même interface, cela passera sans problème.
Elles bénéficient d'un typage structurel. C'est la forme de la fonction qui donne son type et pas son nom. On peut imaginer des langages où tu peut définir le type injectionInt qui est un type de fonction qui pour tout entier te renvoie un entier et qui t'obligerais à déclarer des fonctions add, mult,... comme étant du type injectionInt. Tu n'aurais plus de typage structurel et les même problèmes qu'avec les objets.
Cependant cela demande de penser son interface en avance et c'est donc moins souple. De mon expérience, je suis rarement limité par ce point, mais j'admet cette limitation.
C'est un usage qui arrive pour ceux qui font de grosses bibliothèques (injection de dépendance par exemple).
Merci de m'avoir fourni un exemple valide de l’intérêt d'un typage dynamique.
[^] # Re: Performance
Posté par barmic . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
C'est pas le dynamisme qui joue là, mais le stypage structurel/duck typing.
Elles bénéficient d'un typage structurel. C'est la forme de la fonction qui donne son type et pas son nom. On peut imaginer des langages où tu peut définir le type
injectionIntqui est un type de fonction qui pour tout entier te renvoie un entier et qui t'obligerais à déclarer des fonctionsadd,mult,... comme étant du typeinjectionInt. Tu n'aurais plus de typage structurel et les même problèmes qu'avec les objets.C'est un usage qui arrive pour ceux qui font de grosses bibliothèques (injection de dépendance par exemple).
De rien :)