Dans la discussion reddit, quelqu'un pose la question évidente quand on sait ce qu'est un type somme, et qui résoud les faux-problèmes mentionnés ici:
indil7: Why not model types like in Haskell, with sum/algebraic types and interfaces as just types, not values that can be inspected at runtime for the real type? Those are orthogonal ideas, and they reduce errors by keeping you from breaking the interface abstraction.
J'ai repensé après coup à ça, sur le moment acceptant ceci sans problèmes (rust fait ça avec ses traits), mais, que faire de la reflection si les interfaces ne sont plus des valeurs ? Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.
[^] # Re: go 2.0
Posté par anaseto . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
J'ai repensé après coup à ça, sur le moment acceptant ceci sans problèmes (rust fait ça avec ses traits), mais, que faire de la reflection si les interfaces ne sont plus des valeurs ? Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.