Il n'y a pas de cast explicite, mais dans l'abstrait (peu importe l'implémentation) on peut voir ça comme un cast d'un type implicite qui contiendrait tous les objets (d'un point de vue statique on ne sait en général rien sur le type de l'objet contenu dans une variable, donc interface{}), vers le sous-type des objets qui ont une méthode foo (implicitement défini en Ruby) afin d'appliquer la méthode, avec exception runtime si ce cast échoue (le contenu de la variable, c'est-à-dire l'objet caché derrière interface{}, n'est pas d'un type compatible).
Tu m'a faits douter, mais non le code équivalent en go de ce que j'ai posté plus haut :
./prog.go:26:11: a.foo undefined (type interface {} is interface with no methods)
Go demande à ce que tu indique le type. Tu dois donc définir une interface avec tout ce dont tu as besoin de dans. C'est tout à fait possible et facile dans mon exemple, mais bien plus complexe dans des cas réels. Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.
C'est loin d'être identique dans la logique comme dans le comportement.
[^] # Re: Go est lent, Rust est rouillé !
Posté par barmic 🦦 . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 1.
Tu m'a faits douter, mais non le code équivalent en go de ce que j'ai posté plus haut :
Ça ne compile pas.
Go demande à ce que tu indique le type. Tu dois donc définir une interface avec tout ce dont tu as besoin de dans. C'est tout à fait possible et facile dans mon exemple, mais bien plus complexe dans des cas réels. Donc généralement tu va utiliser un type prédéfini qui possède potentiellement des trucs dont tu n'a pas besoin.
C'est loin d'être identique dans la logique comme dans le comportement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll