[requete http ajax] passage de param callback.

matt a écrit :

Bonsoir,

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();

Attention, ta variable xhr est globale.

var xhr = new XMLHttpRequest();

xhr.onreadystatechange = function(){callBack(xhr, url, gId);};
xhr.open("GET", url, true);

<hs>
Utiliser GET alors que la fonction s'appelle *post*Requete ? Y a pas
comme un problème de nommage, là ?
</hs>

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 ???

C'est normal. Tu récupères la valeur courante de gId au moment de
l'appel de la callback, pas celle au moment de la définition de
onreadystatechange.

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é.

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" ?
Pour ma part, j'ai un doute !...

NB : pas testé non plus

--
Cordialement, Thierry ;-)

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()

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.

--
Cordialement, Thierry ;-)

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).

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

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...

Mes deux centimes...

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

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Bruno Desthuilliers a écrit :

Mes deux centimes...

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.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

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 ?

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