Je n'essaie pas de dire que les interfaces devraient être remplacées par les classes de types, ce sont deux fonctionnalités très différentes (même si elles sont utilisées en partie pour répondre au même besoin).
Puisque tu es intéressé par le fait de discuter des interfaces, poussons un peu la discussion. Go utilise les interfaces de plein de façon différentes :
pour présenter une interface commune à plein de types différents ayant des opérations en commun, en partant du principe qu'il n'y a qu'une seule interface possible pour chaque type; c'est la façon dont marche la généricité sur Writer/Reader par exemple
comme un mécanisme de sealed classes (en Scala) du pauvre où on imite les types sommes en donnant une interface commune à un ensemble de types (un pattern assez proche des "empty bases classes" de C++), et on repose sur le dispatch dynamique sur le sous-type (appelé "type switches" en Go)
interface{} comme un type existentiel fourre-tout suivi par des upcasts quand nécessaire; c'est la programmation générique du pauvre, comme avec Object en Java.
À mon avis les interfaces sont une approche raisonnable pour (1), à comparer par exemple aux "traits" de Rust. (Les type-classes sont beaucoup plus expressives (elles n'imposent pas d'être toujours attachées à une valeur), mais demandent de savoir coder un moteur d'inférence de type plus riche). Je pense que (2) serait, dans la plupart des cas, mieux fait avec des vraies sommes, et que (3) est toujours autant une aberration que quand c'était fait en Java avec Object.
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je n'essaie pas de dire que les interfaces devraient être remplacées par les classes de types, ce sont deux fonctionnalités très différentes (même si elles sont utilisées en partie pour répondre au même besoin).
Puisque tu es intéressé par le fait de discuter des interfaces, poussons un peu la discussion. Go utilise les interfaces de plein de façon différentes :
pour présenter une interface commune à plein de types différents ayant des opérations en commun, en partant du principe qu'il n'y a qu'une seule interface possible pour chaque type; c'est la façon dont marche la généricité sur Writer/Reader par exemple
comme un mécanisme de sealed classes (en Scala) du pauvre où on imite les types sommes en donnant une interface commune à un ensemble de types (un pattern assez proche des "empty bases classes" de C++), et on repose sur le dispatch dynamique sur le sous-type (appelé "type switches" en Go)
interface{}comme un type existentiel fourre-tout suivi par des upcasts quand nécessaire; c'est la programmation générique du pauvre, comme avecObjecten Java.À mon avis les interfaces sont une approche raisonnable pour (1), à comparer par exemple aux "traits" de Rust. (Les type-classes sont beaucoup plus expressives (elles n'imposent pas d'être toujours attachées à une valeur), mais demandent de savoir coder un moteur d'inférence de type plus riche). Je pense que (2) serait, dans la plupart des cas, mieux fait avec des vraies sommes, et que (3) est toujours autant une aberration que quand c'était fait en Java avec
Object.