Je trouve la généricité, les modules très utile. Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible. Cela parait peut être évident pour toi qui est tombé dedans que tu es petit. Mais pour un concept complexe, il faut qu'il ressemble le plus possible à quelques choses de connu (principe UX de moindre surprise). Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
En fait, je pense qu'il doit être possible de proposer des modules en GO mais avec une syntaxe ultra simplifié pour la compréhension.
Genre :
package toto (type t, int i)
func sort(tab t[i]) {...
import "toto"(int, 1024) -> l'idéal serait d'avoir un seul module instancié pour ce couple de paramètre
Pour l’extension d'un package, j'imagine qu'il doit y avoir déjà l'équivalent d'un "open".
[^] # Re: go 2.0
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Je trouve la généricité, les modules très utile. Mais je trouve que leur forme dans ocaml est très complexe et très peu lisible. Cela parait peut être évident pour toi qui est tombé dedans que tu es petit. Mais pour un concept complexe, il faut qu'il ressemble le plus possible à quelques choses de connu (principe UX de moindre surprise). Les modules ressemblent ici vaguement à des objets, avec des définitions de type dedans, mais avec une autre syntaxe.
En fait, je pense qu'il doit être possible de proposer des modules en GO mais avec une syntaxe ultra simplifié pour la compréhension.
Genre :
package toto (type t, int i)
func sort(tab t[i]) {...
import "toto"(int, 1024) -> l'idéal serait d'avoir un seul module instancié pour ce couple de paramètre
Pour l’extension d'un package, j'imagine qu'il doit y avoir déjà l'équivalent d'un "open".
"La première sécurité est la liberté"