J'ai un petit soucis pour passer un paramètre à ma callback.
Je lance plusieurs requêtes de suite avec une fonction postRequete :
// Variable me permettant de savoir combien j'ai lancé de requête
// et combien j'en ai traité
var gId= 0;
// Fonction appelée pour lancer mes requetes
function postRequete(url)
{
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){callBack(xhr, url, gId);};
xhr.open("GET", url, true);
xhr.send(null);
gId++;
}
function callBack(xhr, url, myId)
{
// Ici, myId est toujours = 3 (quand readyState = 4 bien sur)
}
Le problème dans ma callBack, c'est que je ne récupère pas le gId à
l'instant du send mais celui de la dernière valeur.
Par exemple, je pose 2 requêtes avec gId = 0 puis gId = 1 et bien dans
ma callBack je récupère 3 ???
Comment pourrais je faire pour récupérer la bonne valeur ?
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ? Quel est le sens exact de "closure" en JS ?
Bien sûr, si quelqu'un peut expliquer de manière rationnelle que « fermeture » est une traduction intelligente et non littérale, je suis preneur (et je ferais pénitence).
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
-- sm
Mickaël Wolff a écrit :
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ?
"rapprochure" ?
Quel est le sens exact de "closure" en JS ?
Bien sûr, si quelqu'un peut expliquer de manière rationnelle que «
fermeture » est une traduction intelligente et non littérale, je suis
preneur (et je ferais pénitence).
Comme de ttes façons c'est un phénomène incompréhensible, alors ...
un peu + ... un peu - ...
ne va pas changer grd' chose à son intelligibilité.
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ? Quel est le sens exact de "closure" en JS ?
Bien sûr, si quelqu'un peut expliquer de manière rationnelle que « fermeture » est une traduction intelligente et non littérale, je suis preneur (et je ferais pénitence).
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
-- sm
Bruno Desthuilliers
SAM a écrit :
Bruno Desthuilliers a écrit :
Ah, pardon, je n'avais pas compris ton souci. Mais, dis-moi, tu proposerai quoi comme traduction "intelligente" ? Attendu qu'une fermeture "referme" la portée dans laquelle une variable libre est résolue à l'environnement dans lequel la fonction a été définie...
Hu? Hein? et en français ?
Une variable "libre" est une variable utilisée par une fonction mais non définie dans cette fonction. Cette variable doit donc être "résolue" ("valorisée") lors de l'exécution de la fonction. En C, cette variable sera recherchée dans la portée globale, et prendra la valeur de cette variable *au moment de l'exécution* de la fonction. En javascript, et si la fonction est une fonction imbriquée (définie à l'intérieur d'une autre fonction), la variable sera d'abord recherchée dans la portée de la fonction englobante, et prendra la valeur de la variable *au moment de la définition* de la fonction imbriquée - donc au moment de l'appel à la fonction englobante.
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
Sinon, tu peux aussi regarder sur wikipedia http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29 http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>
Nope. Mais pourquoi ne la traduit tu pas ?-)
SAM a écrit :
Bruno Desthuilliers a écrit :
Ah, pardon, je n'avais pas compris ton souci. Mais, dis-moi, tu
proposerai quoi comme traduction "intelligente" ? Attendu qu'une
fermeture "referme" la portée dans laquelle une variable libre est
résolue à l'environnement dans lequel la fonction a été définie...
Hu? Hein? et en français ?
Une variable "libre" est une variable utilisée par une fonction mais non
définie dans cette fonction. Cette variable doit donc être "résolue"
("valorisée") lors de l'exécution de la fonction. En C, cette variable
sera recherchée dans la portée globale, et prendra la valeur de cette
variable *au moment de l'exécution* de la fonction. En javascript, et si
la fonction est une fonction imbriquée (définie à l'intérieur d'une
autre fonction), la variable sera d'abord recherchée dans la portée de
la fonction englobante, et prendra la valeur de la variable *au moment
de la définition* de la fonction imbriquée - donc au moment de l'appel à
la fonction englobante.
En pratique, en Javascript, quand tu a une définition de fonction
imbriquée, un nouvel objet fonction est créé à chaque appel de la
fonction englobante, et si la fonction imbriquée utilise des variables
de la fonction englobante, les "valeurs" *au moment de l'appel à la
fonction englobante* de ces variables sont stockées avec la fonction
imbriquée. Cet ensemble fonction + variables est appelé une fermeture
lexicale.
Ca te va comme définition ?
Sinon, tu peux aussi regarder sur wikipedia
http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29
http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
Ici, les objets retournés par make_adder sont des fermetures constituées
de la fonction anonyme definie dans make_adder et de la valeur de la
variable 'base' dans make_adder au moment de l'appel.
Au fait,
quelqu'un aurait-il une page en fr semblable à celle-ci :
<http://www.jibbering.com/faq/faq_notes/closures.html>
Ah, pardon, je n'avais pas compris ton souci. Mais, dis-moi, tu proposerai quoi comme traduction "intelligente" ? Attendu qu'une fermeture "referme" la portée dans laquelle une variable libre est résolue à l'environnement dans lequel la fonction a été définie...
Hu? Hein? et en français ?
Une variable "libre" est une variable utilisée par une fonction mais non définie dans cette fonction. Cette variable doit donc être "résolue" ("valorisée") lors de l'exécution de la fonction. En C, cette variable sera recherchée dans la portée globale, et prendra la valeur de cette variable *au moment de l'exécution* de la fonction. En javascript, et si la fonction est une fonction imbriquée (définie à l'intérieur d'une autre fonction), la variable sera d'abord recherchée dans la portée de la fonction englobante, et prendra la valeur de la variable *au moment de la définition* de la fonction imbriquée - donc au moment de l'appel à la fonction englobante.
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
Sinon, tu peux aussi regarder sur wikipedia http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29 http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>
Nope. Mais pourquoi ne la traduit tu pas ?-)
SAM
Bruno Desthuilliers a écrit :
SAM a écrit :
Hu? Hein? et en français ?
(...)
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
C'est pas trop mal :-) Je suppose qu'en l'absence de variable dans la fonction mêre on passe alors à celles globales ? (est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num; }; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>
Nope. Mais pourquoi ne la traduit tu pas ?-)
Si je demande c'est bien parce que je me méfie de mon anglais :-(
> Sinon, tu peux aussi regarder sur wikipedia > http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29 > http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
OK.
-- sm
Bruno Desthuilliers a écrit :
SAM a écrit :
Hu? Hein? et en français ?
(...)
En pratique, en Javascript, quand tu a une définition de fonction
imbriquée, un nouvel objet fonction est créé à chaque appel de la
fonction englobante, et si la fonction imbriquée utilise des variables
de la fonction englobante, les "valeurs" *au moment de l'appel à la
fonction englobante* de ces variables sont stockées avec la fonction
imbriquée. Cet ensemble fonction + variables est appelé une fermeture
lexicale.
Ca te va comme définition ?
C'est pas trop mal :-)
Je suppose qu'en l'absence de variable dans la fonction mêre on passe
alors à celles globales ?
(est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur
d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num; }; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures constituées
de la fonction anonyme definie dans make_adder et de la valeur de la
variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
Au fait,
quelqu'un aurait-il une page en fr semblable à celle-ci :
<http://www.jibbering.com/faq/faq_notes/closures.html>
Nope. Mais pourquoi ne la traduit tu pas ?-)
Si je demande c'est bien parce que je me méfie de mon anglais :-(
> Sinon, tu peux aussi regarder sur wikipedia
> http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29
> http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
C'est pas trop mal :-) Je suppose qu'en l'absence de variable dans la fonction mêre on passe alors à celles globales ? (est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num; }; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>
Nope. Mais pourquoi ne la traduit tu pas ?-)
Si je demande c'est bien parce que je me méfie de mon anglais :-(
> Sinon, tu peux aussi regarder sur wikipedia > http://fr.wikipedia.org/wiki/Fermeture_%28informatique%29 > http://fr.wikipedia.org/wiki/Port%C3%A9e_lexicale
OK.
-- sm
Bruno Desthuilliers
SAM a écrit :
Bruno Desthuilliers a écrit :
SAM a écrit :
Hu? Hein? et en français ?
(...)
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
C'est pas trop mal :-) Je suppose qu'en l'absence de variable dans la fonction mêre on passe alors à celles globales ?
En Javascript ? C'est un peu plus compliqué, mais oui, ça tient de ça.
(est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num; }; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
La fermeture est l'ensemble composé par la fonction retournée par make_adder et la valeur de la variable base lors de l'appel.
SAM a écrit :
Bruno Desthuilliers a écrit :
SAM a écrit :
Hu? Hein? et en français ?
(...)
En pratique, en Javascript, quand tu a une définition de fonction
imbriquée, un nouvel objet fonction est créé à chaque appel de la
fonction englobante, et si la fonction imbriquée utilise des variables
de la fonction englobante, les "valeurs" *au moment de l'appel à la
fonction englobante* de ces variables sont stockées avec la fonction
imbriquée. Cet ensemble fonction + variables est appelé une fermeture
lexicale.
Ca te va comme définition ?
C'est pas trop mal :-)
Je suppose qu'en l'absence de variable dans la fonction mêre on passe
alors à celles globales ?
En Javascript ? C'est un peu plus compliqué, mais oui, ça tient de ça.
(est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur
d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num;
}; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures
constituées de la fonction anonyme definie dans make_adder et de la
valeur de la variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
La fermeture est l'ensemble composé par la fonction retournée par
make_adder et la valeur de la variable base lors de l'appel.
En pratique, en Javascript, quand tu a une définition de fonction imbriquée, un nouvel objet fonction est créé à chaque appel de la fonction englobante, et si la fonction imbriquée utilise des variables de la fonction englobante, les "valeurs" *au moment de l'appel à la fonction englobante* de ces variables sont stockées avec la fonction imbriquée. Cet ensemble fonction + variables est appelé une fermeture lexicale.
Ca te va comme définition ?
C'est pas trop mal :-) Je suppose qu'en l'absence de variable dans la fonction mêre on passe alors à celles globales ?
En Javascript ? C'est un peu plus compliqué, mais oui, ça tient de ça.
(est-ce que en l'absence de 'base' dans l'appel, ça va prendre la valeur d'une autre variable de même nom mais globale ? je vais tester voir à voir)
Une illustration "classique":
function make_adder(base) { return function(num) { return base + num; }; }
Oui, similaire vue par ailleurs (dans le fil)
Ici, les objets retournés par make_adder sont des fermetures constituées de la fonction anonyme definie dans make_adder et de la valeur de la variable 'base' dans make_adder au moment de l'appel.
La 'closure' est donc le contenu de la fonction make_adder() ?
La fermeture est l'ensemble composé par la fonction retournée par make_adder et la valeur de la variable base lors de l'appel.
Mickaël Wolff
SAM a écrit :
Mickaël Wolff a écrit :
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu du mal à comprendre le concept.
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript est une plante en terre : en l'arranchant de la terre, tu emporte un peu de terre avec les racines. Ah, encore une idée : une motture ;)
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ?
"rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu
du mal à comprendre le concept.
Comme de ttes façons c'est un phénomène incompréhensible, alors ...
un peu + ... un peu - ...
ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript
est une plante en terre : en l'arranchant de la terre, tu emporte un peu
de terre avec les racines. Ah, encore une idée : une motture ;)
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu du mal à comprendre le concept.
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript est une plante en terre : en l'arranchant de la terre, tu emporte un peu de terre avec les racines. Ah, encore une idée : une motture ;)
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu du mal à comprendre le concept.
>
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript est une plante en terre : en l'arranchant de la terre, tu emporte un peu de terre avec les racines. Ah, encore une idée : une motture ;)
Mouarf ! T'es pas jardinier, toi ?-)
Mickaël Wolff a écrit :
SAM a écrit :
Mickaël Wolff a écrit :
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ?
"rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu
du mal à comprendre le concept.
>
Comme de ttes façons c'est un phénomène incompréhensible, alors ...
un peu + ... un peu - ...
ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript
est une plante en terre : en l'arranchant de la terre, tu emporte un peu
de terre avec les racines. Ah, encore une idée : une motture ;)
je ne vois pas pourquoi closures a été traduit en fermeture.
Et par quoi veux-tu traduire ? "rapprochure" ?
Pas mal ! Je n'y avais pas pensé.
Quel est le sens exact de "closure" en JS ?
Je crois que Bruno te l'a bien expliqué finalement. Moi aussi j'ai eu du mal à comprendre le concept.
>
Comme de ttes façons c'est un phénomène incompréhensible, alors ... un peu + ... un peu - ... ne va pas changer grd' chose à son intelligibilité.
Pas tant que ça. On peut imaginer ça comme si la fonction javascript est une plante en terre : en l'arranchant de la terre, tu emporte un peu de terre avec les racines. Ah, encore une idée : une motture ;)
Mouarf ! T'es pas jardinier, toi ?-)
Mickaël Wolff
Bruno Desthuilliers a écrit :
Mouarf ! T'es pas jardinier, toi ?-)
La seule chose que j'ai jamais fait dans un jardin, c'est chasser les doryphores et biner, mais j'était très jeune. Aujourd'hui, avec mon adresse légendaire, rien ne pousserait ;)
La seule chose que j'ai jamais fait dans un jardin, c'est chasser les
doryphores et biner, mais j'était très jeune. Aujourd'hui, avec mon
adresse légendaire, rien ne pousserait ;)
La seule chose que j'ai jamais fait dans un jardin, c'est chasser les doryphores et biner, mais j'était très jeune. Aujourd'hui, avec mon adresse légendaire, rien ne pousserait ;)
:-D Et encore, pourquoi rationnelles ? Enfin bon, on ne récrira pas le jargon.
Mmm... Je l'avais déjà vue, mais ça ne me plait guère. Pour moi, la clôture évoque plus l'objet qui sert à clore que le fait d'enclore. Tiens, par contre, "enclos", ça pourrait se rapprocher...
Oui, effectivement, mais on pourrait faire encore plus barbare: enclosure !
Pour Javascript, je ne sais pas si c'est exposé par le langage où si ça dépend de l'implémentation, mais dans la mesure où les fonctions javascript sont des objets de première classe, je suppose que c'est stocké dans la structure de données représentant l'objet fonction dans l'implémentation. Y a un guru dans la salle ?
Je suis en train de lire la spécification, il y a visiblement des choses qui m'ont échappée, et j'aime pas ça.
:-D Et encore, pourquoi rationnelles ? Enfin bon, on ne récrira pas
le jargon.
Mmm... Je l'avais déjà vue, mais ça ne me plait guère. Pour moi, la
clôture évoque plus l'objet qui sert à clore que le fait d'enclore.
Tiens, par contre, "enclos", ça pourrait se rapprocher...
Oui, effectivement, mais on pourrait faire encore plus barbare:
enclosure !
Pour Javascript, je ne sais pas si c'est exposé par le langage où si ça
dépend de l'implémentation, mais dans la mesure où les fonctions
javascript sont des objets de première classe, je suppose que c'est
stocké dans la structure de données représentant l'objet fonction dans
l'implémentation. Y a un guru dans la salle ?
Je suis en train de lire la spécification, il y a visiblement des
choses qui m'ont échappée, et j'aime pas ça.
:-D Et encore, pourquoi rationnelles ? Enfin bon, on ne récrira pas le jargon.
Mmm... Je l'avais déjà vue, mais ça ne me plait guère. Pour moi, la clôture évoque plus l'objet qui sert à clore que le fait d'enclore. Tiens, par contre, "enclos", ça pourrait se rapprocher...
Oui, effectivement, mais on pourrait faire encore plus barbare: enclosure !
Pour Javascript, je ne sais pas si c'est exposé par le langage où si ça dépend de l'implémentation, mais dans la mesure où les fonctions javascript sont des objets de première classe, je suppose que c'est stocké dans la structure de données représentant l'objet fonction dans l'implémentation. Y a un guru dans la salle ?
Je suis en train de lire la spécification, il y a visiblement des choses qui m'ont échappée, et j'aime pas ça.
Je ne vois pas en quoi les fermetures sont "sales" (bien au contraire), ni "surprenantes" quant à la portée des variables.
C'est surprenant parce que ça emporte des définitions externes à lui, et qu'en venant du C/C++, on a du mal à concevoir
beaucoup de choses, en fait... Je ne voudrais pas être méchant, mais C n'est pas vraiment un langage très évolué (il n'a d'ailleurs pas été conçu pour), et C++ est une AMHA une monstruosité qui n'aurait jamais dû voir le jour (quand on pense à objective C...).
Mais bon, je trolle^M^M^M^M^M^M^Mdisgresse...
qu'une fonction dépend de l'environnement dans lequel on la déclare. Et ça va à l'encontre de la doctrine objet, pour laquelle on fait tout pour rendre les portées étanches.
Au contraire, les fermetures vont tout à fait dans le sens la POO, puisqu'elles permettent de partager un état entre plusieurs fonctions sans que cet état ne soit accessible autrement. Les afficionados de la programmation fonctionnelle te diront que les objets sont les fermetures du pauvre, les addicts de la POO te diront que les fermetires sont les objets des pauvres, et les vrais maîtres te démontreront qu'il n'y a en fait pas de différence fondamentale entre les deux. De fait, il y a pas mal de choses (application partielle entre autre) dont j'ai vu plusieurs implémentation en Python, certaines utilisant une fermeture, d'autres une classe.
En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser. J'ai vu ce même argument appliqué à la POO, aux fonctions de rappel, aux fonctions récursives, aux messages asynchrones, etc, etc...
mais bon, ça vient aussi de ma haine de l'usage des variables sans déclaration préalable.
??? Je ne vois pas le rapport, là.
Bref, « clôture » me choque moins, et se rapproche plus de l'idée qu'on construit une clôture autour des variables locales pour se les approprier... D'ailleurs, sont-elles copiées où sont-ce des références ?
Là, ça dépend du langage et de l'implémentation... Dans un langage fonctionnel pur, la question n'a d'ailleurs pas de sens puisque les variables sont immuables. En Python, ce sont bien évidemment des références. En Javascript aussi, comme tu peux le vérifier: var myglob = {answer:42}
var func = foo(myglob); func("quelle est la question ?"); alert(myglob.answer);
Mickaël Wolff a écrit :
Bruno Desthuilliers a écrit :
Je ne vois pas en quoi les fermetures sont "sales" (bien au
contraire), ni "surprenantes" quant à la portée des variables.
C'est surprenant parce que ça emporte des définitions externes à lui,
et qu'en venant du C/C++, on a du mal à concevoir
beaucoup de choses, en fait... Je ne voudrais pas être méchant, mais C
n'est pas vraiment un langage très évolué (il n'a d'ailleurs pas été
conçu pour), et C++ est une AMHA une monstruosité qui n'aurait jamais dû
voir le jour (quand on pense à objective C...).
Mais bon, je trolle^M^M^M^M^M^M^Mdisgresse...
qu'une fonction dépend
de l'environnement dans lequel on la déclare. Et ça va à l'encontre de
la doctrine objet, pour laquelle on fait tout pour rendre les portées
étanches.
Au contraire, les fermetures vont tout à fait dans le sens la POO,
puisqu'elles permettent de partager un état entre plusieurs fonctions
sans que cet état ne soit accessible autrement. Les afficionados de la
programmation fonctionnelle te diront que les objets sont les fermetures
du pauvre, les addicts de la POO te diront que les fermetires sont les
objets des pauvres, et les vrais maîtres te démontreront qu'il n'y a en
fait pas de différence fondamentale entre les deux. De fait, il y a pas
mal de choses (application partielle entre autre) dont j'ai vu plusieurs
implémentation en Python, certaines utilisant une fermeture, d'autres
une classe.
En fait,le plus gros problème est qu'on peut se retrouver avec des
comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser.
J'ai vu ce même argument appliqué à la POO, aux fonctions de rappel, aux
fonctions récursives, aux messages asynchrones, etc, etc...
mais bon, ça vient aussi de ma
haine de l'usage des variables sans déclaration préalable.
??? Je ne vois pas le rapport, là.
Bref, « clôture » me choque moins, et se rapproche plus de l'idée
qu'on construit une clôture autour des variables locales pour se les
approprier... D'ailleurs, sont-elles copiées où sont-ce des références ?
Là, ça dépend du langage et de l'implémentation... Dans un langage
fonctionnel pur, la question n'a d'ailleurs pas de sens puisque les
variables sont immuables. En Python, ce sont bien évidemment des
références. En Javascript aussi, comme tu peux le vérifier:
var myglob = {answer:42}
Je ne vois pas en quoi les fermetures sont "sales" (bien au contraire), ni "surprenantes" quant à la portée des variables.
C'est surprenant parce que ça emporte des définitions externes à lui, et qu'en venant du C/C++, on a du mal à concevoir
beaucoup de choses, en fait... Je ne voudrais pas être méchant, mais C n'est pas vraiment un langage très évolué (il n'a d'ailleurs pas été conçu pour), et C++ est une AMHA une monstruosité qui n'aurait jamais dû voir le jour (quand on pense à objective C...).
Mais bon, je trolle^M^M^M^M^M^M^Mdisgresse...
qu'une fonction dépend de l'environnement dans lequel on la déclare. Et ça va à l'encontre de la doctrine objet, pour laquelle on fait tout pour rendre les portées étanches.
Au contraire, les fermetures vont tout à fait dans le sens la POO, puisqu'elles permettent de partager un état entre plusieurs fonctions sans que cet état ne soit accessible autrement. Les afficionados de la programmation fonctionnelle te diront que les objets sont les fermetures du pauvre, les addicts de la POO te diront que les fermetires sont les objets des pauvres, et les vrais maîtres te démontreront qu'il n'y a en fait pas de différence fondamentale entre les deux. De fait, il y a pas mal de choses (application partielle entre autre) dont j'ai vu plusieurs implémentation en Python, certaines utilisant une fermeture, d'autres une classe.
En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser. J'ai vu ce même argument appliqué à la POO, aux fonctions de rappel, aux fonctions récursives, aux messages asynchrones, etc, etc...
mais bon, ça vient aussi de ma haine de l'usage des variables sans déclaration préalable.
??? Je ne vois pas le rapport, là.
Bref, « clôture » me choque moins, et se rapproche plus de l'idée qu'on construit une clôture autour des variables locales pour se les approprier... D'ailleurs, sont-elles copiées où sont-ce des références ?
Là, ça dépend du langage et de l'implémentation... Dans un langage fonctionnel pur, la question n'a d'ailleurs pas de sens puisque les variables sont immuables. En Python, ce sont bien évidemment des références. En Javascript aussi, comme tu peux le vérifier: var myglob = {answer:42}
var func = foo(myglob); func("quelle est la question ?"); alert(myglob.answer);
SAM
Bruno Desthuilliers a écrit :
Mickaël Wolff a écrit :
Bruno Desthuilliers a écrit :
En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser.
Ben ... faut dire ... l'ouvrier a bien du mal ! Ces fonctions à tiroirs faut vraiment arriver à suivre :-(
En Python, ce sont bien évidemment des références. En Javascript aussi, comme tu peux le vérifier:
J'ai regardé dans un brouteur et ... j'ai rien compris : - Yè souis perdou (dès la ligne 4 : à quoi se réfère new_data?) - et à quoi sert myglob finalement ? (alert("quelle est la question ?"); suffit bien) - je comprends seulement qu'on a bousillé myglob (on n'a pas besoin d'enfermements pour modifier une globale) (comment je peux retrouver l'original myglob.answer ?)
var func = foo(myglob); func("quelle est la question ?"); alert(myglob.answer);
Là, d'un troll, on va devoir passer à faire ouvrir un nouveau ng rien que pour ce sujet !
-- sm
Bruno Desthuilliers a écrit :
Mickaël Wolff a écrit :
Bruno Desthuilliers a écrit :
En fait,le plus gros problème est qu'on peut se retrouver avec des
comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser.
Ben ... faut dire ... l'ouvrier a bien du mal !
Ces fonctions à tiroirs faut vraiment arriver à suivre :-(
En Python, ce sont bien évidemment des références.
En Javascript aussi, comme tu peux le vérifier:
J'ai regardé dans un brouteur et ... j'ai rien compris :
- Yè souis perdou (dès la ligne 4 : à quoi se réfère new_data?)
- et à quoi sert myglob finalement ?
(alert("quelle est la question ?"); suffit bien)
- je comprends seulement qu'on a bousillé myglob
(on n'a pas besoin d'enfermements pour modifier une globale)
(comment je peux retrouver l'original myglob.answer ?)
En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas...
Ce n'est pas de la faute de l'outil si l'ouvrier ne sait pas l'utiliser.
Ben ... faut dire ... l'ouvrier a bien du mal ! Ces fonctions à tiroirs faut vraiment arriver à suivre :-(
En Python, ce sont bien évidemment des références. En Javascript aussi, comme tu peux le vérifier:
J'ai regardé dans un brouteur et ... j'ai rien compris : - Yè souis perdou (dès la ligne 4 : à quoi se réfère new_data?) - et à quoi sert myglob finalement ? (alert("quelle est la question ?"); suffit bien) - je comprends seulement qu'on a bousillé myglob (on n'a pas besoin d'enfermements pour modifier une globale) (comment je peux retrouver l'original myglob.answer ?)
