En préambule, notons que je ne suis pas la personne à qui tu répondais au début. Je ne cherche pas à « avoir raison » à tout prix, mais simplement il y a tout un tas de gens qui utilisent des langages non déclaratifs, non fonctionnels, et qui ont un réel intérêt à utiliser des globales dans ce contexte.
J'ai un peu de mal à comprendre ce que tu veux dire, mais j'ai l'impression que tu te compliques la vie : une variable en Erlang est comme une variable en C/Java, à quelques différences près :
- tu ne peux pas déclarer de variable en dehors d'une fonction
- tu ne peux affecter qu'une seule valeur à une variable.
Ben, « valeur » = variable à affectation unique. C'est peut-être un peu pédant comme terminologie, mais c'est celle qui est utilisée par une bonne partie des gens qui font des langages et de la compilation (« single assignment »). Le fait que tes variables soient aussi confinées à l'intérieur d'une fonction fait aussi que tes fonctions semblent devenir pures. Du coup, j'aimerais savoir ce qui te fait dire qu'Erlang n'est pas un langage fonctionnel pur1.
J'ai l'impression que tu cherches à tout prix à avoir raison. Tu peux tourner les choses dans le sens que tu veux, il n'y a pas de variable globale en Erlang.
Absolument pas. Je suis intervenu dans la discussion parce que s'il n'y a pas de variable globale, je me demande comment on fait pour passer un (ensemble d')état(s) entre différents processus. Internet me dit « passage de message », ce qui implicitement indique une sérialisation des valeurs en cas de « conflit » (si 2 processus veulent modifier la même valeur qui est rendue accessible/visible par un processus Erlang).
Je n'ai jamais dit le contraire, je suis seulement d'avis qu'utiliser une variable pour ça est une mauvaise idée. La Lisibilité du code est une raison (qui pour moi est suffisante à elle seule).
Et comme d'habitude, tout dépend du contexte. :-) _kaos_ donnait l'exemple d'un mutex globalement accessible. Bon, perso, je créerais quand même une structure de données pour encapsuler le machin, mais c'est parce que j'aime pas les gros verrous qui deviennent potentiellement de gros points de contention dans une appli. Mais son exemple est parfaitement sûr : la sémantique-même d'une variable d'exclusion mutuelle impose de passer par des fonctions qui garantissent l'accès exclusif. Donc un mutex déclaré globalement, à défaut d'être performant, est sûr.
Note qu'évidemment, n'importe quel langage fonctionnel, même pur, doit pouvoir opérer des effets de bord, sinon on n'écrirait jamais « définitivement » en mémoire. ↩
[^] # Re: jeNeSaisPasCommentNommerCetteVariable
Posté par lasher . En réponse au journal Comment être un développeur désirable. Évalué à 4.
En préambule, notons que je ne suis pas la personne à qui tu répondais au début. Je ne cherche pas à « avoir raison » à tout prix, mais simplement il y a tout un tas de gens qui utilisent des langages non déclaratifs, non fonctionnels, et qui ont un réel intérêt à utiliser des globales dans ce contexte.
Ben, « valeur » = variable à affectation unique. C'est peut-être un peu pédant comme terminologie, mais c'est celle qui est utilisée par une bonne partie des gens qui font des langages et de la compilation (« single assignment »). Le fait que tes variables soient aussi confinées à l'intérieur d'une fonction fait aussi que tes fonctions semblent devenir pures. Du coup, j'aimerais savoir ce qui te fait dire qu'Erlang n'est pas un langage fonctionnel pur1 .
Absolument pas. Je suis intervenu dans la discussion parce que s'il n'y a pas de variable globale, je me demande comment on fait pour passer un (ensemble d')état(s) entre différents processus. Internet me dit « passage de message », ce qui implicitement indique une sérialisation des valeurs en cas de « conflit » (si 2 processus veulent modifier la même valeur qui est rendue accessible/visible par un processus Erlang).
Et comme d'habitude, tout dépend du contexte. :-) _kaos_ donnait l'exemple d'un mutex globalement accessible. Bon, perso, je créerais quand même une structure de données pour encapsuler le machin, mais c'est parce que j'aime pas les gros verrous qui deviennent potentiellement de gros points de contention dans une appli. Mais son exemple est parfaitement sûr : la sémantique-même d'une variable d'exclusion mutuelle impose de passer par des fonctions qui garantissent l'accès exclusif. Donc un mutex déclaré globalement, à défaut d'être performant, est sûr.
Note qu'évidemment, n'importe quel langage fonctionnel, même pur, doit pouvoir opérer des effets de bord, sinon on n'écrirait jamais « définitivement » en mémoire. ↩