Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,...), et tout le monde la comprend pareil. Idem pour l’interface Error.
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
Oui, je n'ai pas été très clair (et un truc m'échappe peut-être), mais en gros, comme ton interface est inférée implicitement, si tout le monde fait bien attention, alors ça va aller, mais imagine qu'une personne implémente un read et un write qui ne sont pas compatible (pour une raison qui m'échappe :) alors est-ce que cette chose implémente ReadWriter ou juste Reader et Writer ?
Ce qui m'embête c'est cet implicite qui ne rend pas les choses explicites : quand je dis que j'implémente ReaderWriter, je signe un contrat pour une sémantique particulière, et peut-être qu'il y a plusieurs ReaderWriter, selon la sémantique.
Quand j'implémente une méthode read, j'implémente une méthode read et je met la signification que je veux derrière.
Sinon, avec des interfaces moins utilisées, des signification différentes vont émerger dans différentes parties du monde et un jour un mec va dire : ah zut, on a pas pareil, il faut se sync ! Ah oui mais merde, on est incapable de savoir à quelle sémantique ce rapporte cette implémentation ou celle-ci. Avec des interfaces, on a juste à regarder de quelle interface on parle (sans oublier qu'il y a un namespace qui permet de différencier les interfaces avec le même nom et ce, par le compilateur, pas un humain !).
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
Le fait que le lien méthode / interface est implicite avec le structural typing.
Dans Go, l'interface ne sert que à donner des jolis noms à une définition structurelle d'un type, avec des interfaces à la Java, c'est plus qu'un nom, c'est un contrat à signer par ses implémenteurs.
[^] # Re: Mais sinon, pourquoi je devrais m'intéresser à ce énième langage
Posté par Victor . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 6.
Je crois que tu n’as pas compris leur système d’interfaces. Une même interface est comprise pareille pour tout le monde. Si tu fais un minimum de Go, tu verras par exemple que l’interface Reader est utilisée absolument partout (dans io, http, json, logger,...), et tout le monde la comprend pareil. Idem pour l’interface Error.
Ben oui, c’est ce que fait une interface en Go ; un ReadWriter, c’est un objet sur lequel on peut lire et écrire.
Ou alors j’ai pas compris ce que tu voulais dire par « donner une sémantique à ses méthodes ».
Oui, je n'ai pas été très clair (et un truc m'échappe peut-être), mais en gros, comme ton interface est inférée implicitement, si tout le monde fait bien attention, alors ça va aller, mais imagine qu'une personne implémente un read et un write qui ne sont pas compatible (pour une raison qui m'échappe :) alors est-ce que cette chose implémente ReadWriter ou juste Reader et Writer ?
Ce qui m'embête c'est cet implicite qui ne rend pas les choses explicites : quand je dis que j'implémente ReaderWriter, je signe un contrat pour une sémantique particulière, et peut-être qu'il y a plusieurs ReaderWriter, selon la sémantique.
Quand j'implémente une méthode read, j'implémente une méthode read et je met la signification que je veux derrière.
Sinon, avec des interfaces moins utilisées, des signification différentes vont émerger dans différentes parties du monde et un jour un mec va dire : ah zut, on a pas pareil, il faut se sync ! Ah oui mais merde, on est incapable de savoir à quelle sémantique ce rapporte cette implémentation ou celle-ci. Avec des interfaces, on a juste à regarder de quelle interface on parle (sans oublier qu'il y a un namespace qui permet de différencier les interfaces avec le même nom et ce, par le compilateur, pas un humain !).
> et là, justement ce n'est que du structural typing statiquement typé !
En quoi est-ce supposé être en contradiction ?
Le fait que le lien méthode / interface est implicite avec le structural typing.
Dans Go, l'interface ne sert que à donner des jolis noms à une définition structurelle d'un type, avec des interfaces à la Java, c'est plus qu'un nom, c'est un contrat à signer par ses implémenteurs.
Et si tu manques de flexibilité et d'ouverture, il existe d'autres solutions qui s'inspire des type classes :
http://ropas.snu.ac.kr/~bruno/papers/TypeClasses.pdf
Sur le typage avancé :
Pour le concept : http://www.cs.kuleuven.be/~adriaan/files/genericshk/tcpoly-o(...)
Pour son utilisation :
http://drops.dagstuhl.de/opus/volltexte/2009/2338/
http://www.comlab.ox.ac.uk//files/2187/ModularVisitor.pdf
Pour la réflexion object / fonctionnel :
http://infoscience.epfl.ch/getfile.py?docid=13847&name=T(...)
Mais bon, ensuite il faut fouiller le web, il y a des millions de trucs passionnants :
http://www.scala-lang.org/node/143