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 ?
(...) Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url) { var myId = gId++; // copie locale puis incrément var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){callBack(xhr, url, myId);}; xhr.open("GET", url, true); xhr.send(null); }
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant des variables locales à "getRequete" ? Pour ma part, j'ai un doute !...
NB : pas testé non plus
-- Cordialement, Thierry ;-)
Bruno Desthuilliers
Cenekemoi a écrit :
Bonjour à Bruno Desthuilliers qui nous a écrit :
matt a écrit :
(...) Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url) { var myId = gId++; // copie locale puis incrément var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){callBack(xhr, url, myId);}; xhr.open("GET", url, true); xhr.send(null); }
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales (en d'autres termes, elles "capturent" l'environnement dans lequel elles sont définies). J'utilise cet idiome très fréquemment, aussi bien en Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...) # function toto(myvar) { alert("myvar : " + myvar); } # var XXX = 42 # function tata() {var myXXX=XXX++; return function(){toto(myXXX); };} # var f = tata() # f() # var f2 = tata() # f2()
Cenekemoi a écrit :
Bonjour à Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> qui nous a écrit :
matt a écrit :
(...)
Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url)
{
var myId = gId++; // copie locale puis incrément
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){callBack(xhr, url, myId);};
xhr.open("GET", url, true);
xhr.send(null);
}
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant
des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales
(en d'autres termes, elles "capturent" l'environnement dans lequel elles
sont définies). J'utilise cet idiome très fréquemment, aussi bien en
Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...)
# function toto(myvar) { alert("myvar : " + myvar); }
# var XXX = 42
# function tata() {var myXXX=XXX++; return function(){toto(myXXX); };}
# var f = tata()
# f()
# var f2 = tata()
# f2()
(...) Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url) { var myId = gId++; // copie locale puis incrément var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){callBack(xhr, url, myId);}; xhr.open("GET", url, true); xhr.send(null); }
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales (en d'autres termes, elles "capturent" l'environnement dans lequel elles sont définies). J'utilise cet idiome très fréquemment, aussi bien en Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...) # function toto(myvar) { alert("myvar : " + myvar); } # var XXX = 42 # function tata() {var myXXX=XXX++; return function(){toto(myXXX); };} # var f = tata() # f() # var f2 = tata() # f2()
Cenekemoi
Bonjour à Bruno Desthuilliers qui nous a écrit :
Cenekemoi a écrit :
Bonjour à Bruno Desthuilliers qui nous a écrit :
matt a écrit :
(...) Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url) { var myId = gId++; // copie locale puis incrément var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){callBack(xhr, url, myId);}; xhr.open("GET", url, true); xhr.send(null); }
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales (en d'autres termes, elles "capturent" l'environnement dans lequel elles sont définies). J'utilise cet idiome très fréquemment, aussi bien en Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...) # function toto(myvar) { alert("myvar : " + myvar); } # var XXX = 42 # function tata() {var myXXX=XXX++; return function(){toto(myXXX); };} # var f = tata() # f() # var f2 = tata() # f2()
OK, au temps pour moi !...
...et merci pour les "fermetures lexicales", je ne connaissais pas le terme.
-- Cordialement, Thierry ;-)
Bonjour à Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> qui nous a écrit :
Cenekemoi a écrit :
Bonjour à Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> qui nous a écrit :
matt a écrit :
(...)
Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url)
{
var myId = gId++; // copie locale puis incrément
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){callBack(xhr, url, myId);};
xhr.open("GET", url, true);
xhr.send(null);
}
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en
utilisant des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales
(en d'autres termes, elles "capturent" l'environnement dans lequel
elles sont définies). J'utilise cet idiome très fréquemment, aussi
bien en Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...)
# function toto(myvar) { alert("myvar : " + myvar); }
# var XXX = 42
# function tata() {var myXXX=XXX++; return function(){toto(myXXX); };}
# var f = tata()
# f()
# var f2 = tata()
# f2()
OK, au temps pour moi !...
...et merci pour les "fermetures lexicales", je ne connaissais pas le
terme.
(...) Comment pourrais je faire pour récupérer la bonne valeur ?
Utiliser une variable intermédiaire ?
function getRequete(url) { var myId = gId++; // copie locale puis incrément var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){callBack(xhr, url, myId);}; xhr.open("GET", url, true); xhr.send(null); }
NB : pas testé.
Attention, est-tu sûr que l'appel à "callBack" va marcher en utilisant des variables locales à "getRequete" ?
Oui, pourquoi ? Les fonctions Javascript sont des fermetures lexicales (en d'autres termes, elles "capturent" l'environnement dans lequel elles sont définies). J'utilise cet idiome très fréquemment, aussi bien en Javascript qu'en Python.
Pour ma part, j'ai un doute !...
Tu ne devrais pas:
## (session firebug...) # function toto(myvar) { alert("myvar : " + myvar); } # var XXX = 42 # function tata() {var myXXX=XXX++; return function(){toto(myXXX); };} # var f = tata() # f() # var f2 = tata() # f2()
OK, au temps pour moi !...
...et merci pour les "fermetures lexicales", je ne connaissais pas le terme.
-- Cordialement, Thierry ;-)
Mickaël Wolff
Bruno Desthuilliers a écrit :
Oui, pourquoi ?
C'est perturbant quant on vient de langages propres, sans surprises quand à la portée des variables.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En anglais on dit closures, et je ne vois pas pourquoi closures a été traduit en fermeture.
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).
C'est perturbant quant on vient de langages propres, sans surprises
quand à la portée des variables.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En
anglais on dit closures, et je ne vois pas pourquoi closures a été
traduit en fermeture.
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).
C'est perturbant quant on vient de langages propres, sans surprises quand à la portée des variables.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En anglais on dit closures, et je ne vois pas pourquoi closures a été traduit en fermeture.
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).
C'est perturbant quant on vient de langages propres, sans surprises quand à la portée des variables.
Je ne vois pas en quoi les fermetures sont "sales" (bien au contraire), ni "surprenantes" quant à la portée des variables. Je trouve bien plus sale et surprenant le fonctionnement de certain "langage" dans lequel une fonction imbriquée se retrouve en fait définie dans l'espace de nommage global... Le dit "langage" est d'ailleur le seul langage "de haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que partiellement, le concept de fermeture lexicale.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En anglais on dit closures, et je ne vois pas pourquoi closures a été traduit en fermeture.
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
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).
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...
Mes deux centimes...
Mickaël Wolff a écrit :
Bruno Desthuilliers a écrit :
Oui, pourquoi ?
C'est perturbant quant on vient de langages propres, sans surprises
quand à la portée des variables.
Je ne vois pas en quoi les fermetures sont "sales" (bien au contraire),
ni "surprenantes" quant à la portée des variables. Je trouve bien plus
sale et surprenant le fonctionnement de certain "langage" dans lequel
une fonction imbriquée se retrouve en fait définie dans l'espace de
nommage global... Le dit "langage" est d'ailleur le seul langage "de
haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que
partiellement, le concept de fermeture lexicale.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En
anglais on dit closures, et je ne vois pas pourquoi closures a été
traduit en fermeture.
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de
mon fils), mais si mon souvenir est bon, fermeture est la traduction
littérale de closure. Ceci explique peut-être cela ?-)
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).
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...
C'est perturbant quant on vient de langages propres, sans surprises quand à la portée des variables.
Je ne vois pas en quoi les fermetures sont "sales" (bien au contraire), ni "surprenantes" quant à la portée des variables. Je trouve bien plus sale et surprenant le fonctionnement de certain "langage" dans lequel une fonction imbriquée se retrouve en fait définie dans l'espace de nommage global... Le dit "langage" est d'ailleur le seul langage "de haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que partiellement, le concept de fermeture lexicale.
Les fonctions Javascript sont des fermetures lexicales
Je cherche qui est le débile qui a fait cette traduction stupide. En anglais on dit closures, et je ne vois pas pourquoi closures a été traduit en fermeture.
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
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).
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...
Mes deux centimes...
Mickaël Wolff
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 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. En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas... mais bon, ça vient aussi de ma haine de l'usage des variables sans déclaration préalable.
Et si j'avais su ça il y a deux ans, je me serais moins arraché la tête sur comment faire passer des informations à XHR.onstatechange (je tarabiscotait à coup d'eval).
Je trouve bien plus sale et surprenant le fonctionnement de certain "langage" dans lequel une fonction imbriquée se retrouve en fait définie dans l'espace de nommage global... Le dit "langage" est d'ailleur le seul langage "de haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que partiellement, le concept de fermeture lexicale.
C'est disponible dans la version 5.3 ;) Mais c'est vrai que le langage auquel tu fais allusion n'est pas pensé ni propre (avouons-le, c'est un langage à la rache).
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de « to close » dans l'expression « I am close to you ». Cette expression ne signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt qu'on en est proche, dans son périmètre, une proximité comme diraient les Québécois.
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 ? Mais j'aurais proposé « proximature », ou « proximateur » pour faire mon intéressant, si j'avais eu à choisir :p
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 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.
En fait,le plus gros problème est qu'on peut se retrouver avec des
comportements qu'on ne comprend pas... mais bon, ça vient aussi de ma
haine de l'usage des variables sans déclaration préalable.
Et si j'avais su ça il y a deux ans, je me serais moins arraché la
tête sur comment faire passer des informations à XHR.onstatechange (je
tarabiscotait à coup d'eval).
Je trouve bien plus
sale et surprenant le fonctionnement de certain "langage" dans lequel
une fonction imbriquée se retrouve en fait définie dans l'espace de
nommage global... Le dit "langage" est d'ailleur le seul langage "de
haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que
partiellement, le concept de fermeture lexicale.
C'est disponible dans la version 5.3 ;) Mais c'est vrai que le
langage auquel tu fais allusion n'est pas pensé ni propre (avouons-le,
c'est un langage à la rache).
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de
mon fils), mais si mon souvenir est bon, fermeture est la traduction
littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de «
to close » dans l'expression « I am close to you ». Cette expression ne
signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt
qu'on en est proche, dans son périmètre, une proximité comme diraient
les Québécois.
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 ?
Mais j'aurais proposé « proximature », ou « proximateur » pour faire mon
intéressant, si j'avais eu à choisir :p
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 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. En fait,le plus gros problème est qu'on peut se retrouver avec des comportements qu'on ne comprend pas... mais bon, ça vient aussi de ma haine de l'usage des variables sans déclaration préalable.
Et si j'avais su ça il y a deux ans, je me serais moins arraché la tête sur comment faire passer des informations à XHR.onstatechange (je tarabiscotait à coup d'eval).
Je trouve bien plus sale et surprenant le fonctionnement de certain "langage" dans lequel une fonction imbriquée se retrouve en fait définie dans l'espace de nommage global... Le dit "langage" est d'ailleur le seul langage "de haut niveau" que j'utilises qui n'implémente pas, ne serait-ce que partiellement, le concept de fermeture lexicale.
C'est disponible dans la version 5.3 ;) Mais c'est vrai que le langage auquel tu fais allusion n'est pas pensé ni propre (avouons-le, c'est un langage à la rache).
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de « to close » dans l'expression « I am close to you ». Cette expression ne signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt qu'on en est proche, dans son périmètre, une proximité comme diraient les Québécois.
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 ? Mais j'aurais proposé « proximature », ou « proximateur » pour faire mon intéressant, si j'avais eu à choisir :p
Je suis en train de me rendre compte que j'utilisais les closures. Et je comprends mieux pourquoi mes « variable privées » n'étaient pas propagées au fonctions que j'appliquait à l'aide Function.apply sur mes objets.
Je suis en train de me rendre compte que j'utilisais les closures. Et
je comprends mieux pourquoi mes « variable privées » n'étaient pas
propagées au fonctions que j'appliquait à l'aide Function.apply sur mes
objets.
Je suis en train de me rendre compte que j'utilisais les closures. Et je comprends mieux pourquoi mes « variable privées » n'étaient pas propagées au fonctions que j'appliquait à l'aide Function.apply sur mes objets.
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
Tu veux parler des expressions rationelles ?-)
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de « to close » dans l'expression « I am close to you ». Cette expression ne signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt qu'on en est proche, dans son périmètre, une proximité comme diraient les Québécois.
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...
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...
D'ailleurs, sont-elles copiées où sont-ce des références ?
Je peux te répondre clairement pour Python : dans l'attribut func_closure, sous la forme d'un tuple d'objets Cell qui eux-même wrappent la référence à la variable.
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 ?
Mickaël Wolff a écrit :
Bruno Desthuilliers a écrit :
(snip)
Je n'ai pas mon harraps sous le coude (il doit être dans la chambre de
mon fils), mais si mon souvenir est bon, fermeture est la traduction
littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
Tu veux parler des expressions rationelles ?-)
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de « to
close » dans l'expression « I am close to you ». Cette expression ne
signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt
qu'on en est proche, dans son périmètre, une proximité comme diraient
les Québécois.
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...
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...
D'ailleurs, sont-elles copiées où sont-ce des références ?
Je peux te répondre clairement pour Python : dans l'attribut
func_closure, sous la forme d'un tuple d'objets Cell qui eux-même
wrappent la référence à la variable.
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 n'ai pas mon harraps sous le coude (il doit être dans la chambre de mon fils), mais si mon souvenir est bon, fermeture est la traduction littérale de closure. Ceci explique peut-être cela ?-)
Justement, c'est comme regular expression, mal traduit.
Tu veux parler des expressions rationelles ?-)
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...
Ben en fait, pour moi le terme « closure » se rapporte au sens de « to close » dans l'expression « I am close to you ». Cette expression ne signifiant pas qu'on est fermé à quelqu'un ou de quelqu'un. C'est plutôt qu'on en est proche, dans son périmètre, une proximité comme diraient les Québécois.
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...
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...
D'ailleurs, sont-elles copiées où sont-ce des références ?
Je peux te répondre clairement pour Python : dans l'attribut func_closure, sous la forme d'un tuple d'objets Cell qui eux-même wrappent la référence à la variable.
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 ?
SAM
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 ?
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>
-- sm
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 ?
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 ?
Au fait, quelqu'un aurait-il une page en fr semblable à celle-ci : <http://www.jibbering.com/faq/faq_notes/closures.html>