Testez vos connaissances avec un Quiz sur l'usage avancé des fonctions en JavaScript

C'est-à-dire ? Si tu as un exemple je suis curieux de voir les différences avec ou non l'activation du strict mode :)

Merci NoSmoking pour l'explication. C'est vrai que l'écriture "Macro" est plus familière.

Votre score : 5 / 10 :?


Il n'y a que les questions sur les closure où j'étais certain des réponses, le reste j'ai tenté ce qui me semblait le plus logique mais ça n'a pas vraiment fonctionné. :aie:

Et pour la question Bonus, définitivement la réponse D :lol:

Citation:

---

Envoyé par Kaamo

C'est-à-dire ? Si tu as un exemple je suis curieux de voir les différences avec ou non l'activation du strict mode :)

Merci NoSmoking pour l'explication. C'est vrai que l'écriture "Macro" est plus familière.

---

Facile...

À la question 2...

Code:

---

a.name = "d"

---

À la question 4...

Code:

---

arguments.callee

---

... lèveront une exception

À la question 7, la proposition 1 retournera undefined

... bref, 7/10 pour SylvainPV :mrgreen:

Si l'on était en mode strict, je l'aurais précisé... A la question 2 et 4, aucune des propositions ne mentionnent une exception donc on ne pouvait pas se tromper. Et mode strict ou pas, la proposition 1 de la question 7 reste la proposition 1 de la question 7. Pourquoi voudrais-tu qu'elle change ?

Désolé Lcf, il va te falloir trouver une autre excuse pour tes points perdus :mrgreen:

Bah, je ne cherchais pas d'excuses, surtout avec un 9/10, tout comme je ne disais pas que j'y ai répondu en me basant sur le strict mode, juste que je trouve dommage d'encore illustrer du non-strict.

Et, pour la question 7, je voulais simplement dire qu'en strict mode, l'explication de la première proposition ne tient plus. ;)

Citation:

---

Envoyé par SylvainPV

On peut en effet s'en servir pour se passer de 'this', ou éviter un appel manuel à call, donc la bonne proposition de la Q11 est la B :

Code:

---

var cloneArray = Function.bind.bind(Function.call)(Array.prototype.slice);

---

---

Autant j'aime beaucoup le binding, autant il faut quand même faire gaffe à ne pas en abuser car son coût, en performances, est assez désastreux.

À titre d'exemple, avec le code en citation, 1 seul appel à cloneArray coûte environ 17 fois un appel à Array.slice.call :

• Le bindind, lui-même : 15.3 fois
• Chaque appel : 1.7 fois

Donc, réponse "e", à perdre en performances? :mouarf:

Tu es sûr de tes tests ? La différence est mineure pour moi sur Chrome

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

console.time("cloneArray"); for(var i=0; i<99999; i++){ Array.prototype.slice.call([1,2,3]); } console.timeEnd("cloneArray");   // cloneArray: 102.637ms   var cloneArray = Function.bind.bind(Function.call)(Array.prototype.slice); console.time("cloneArray bbc"); for(var i=0; i<99999; i++){ cloneArray([1,2,3]); } console.timeEnd("cloneArray bbc");   // cloneArray bbc: 111.255ms

---

Perso, je n'ai pas testé en termes de vitesse d'exécution mais en termes de mémoire utilisée ;)

Je ne vois pas pourquoi bind ferait augmenter 17 fois la mémoire utilisée. Tu as une suite de test à montrer ? Comment repères-tu la mémoire allouée spécifiquement pour une portion de code ?

Avec la Heap Timeline de l'inspecteur Chrome, j'observe au contraire un pic de mémoire plus haut pour la méthode sans bind : http://i.imgur.com/SSqO3N2.png ; bien que je ne sois pas un expert en allocation mémoire, peut-être que je me trompe dans l'interprétation de ces résultats.

Hum, mea culpa, j'ai dû mal interpréter les chiffres :oops:

Le binding est coûteux, très coûteux mais les appels sont sacrément plus performants avec ton code.

Pour ce qui est de tester l'usage de la mémoire, j'fais cela sous node ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

var i, heap, cloneArray;   i = 0; heap = process.memoryUsage().heapUsed; cloneArray = Function.bind.bind(Function.call)(Array.prototype.slice);   for (; i < 99999; i += 1) { /*/   Array.prototype.slice.call([1,2,3]); // 1170304   /*/ cloneArray([1,2,3]); // 688264 //*/ }   console.log(process.memoryUsage().heapUsed - heap);

---

On est d'accord que ce sont des tests pour de faux ? :D alors j'ai testé en plus
[1,2,3].slice() bin pas besoin d'acrobaties pour "cloner" un tableau, et c'est encore la version la plus rapide :D
Mais aussi une bête fonction genre: clone = new Array(array.length) et un boucle de copie for ( var i= .... C'est aussi rapide que slice.call étonnament enfin avec Rhino et Ffx.
Et qu'est-ce que vous faites du gc ? et les optimisations sur la création des tableaux ? et les optimisations tout court des moteurs ? et puis dans un navigateur ... Mm ... M'enfin, j'arrive à des écarts à peu près stables entre la version la plus lente et la plus rapide de l'ordre de 15 à 20%
Et avec cloneArray = Function.call.bind(Array.prototype.slice) ça vous donne quoi ? :mouarf:

On est partis sur un débat sur les performances assez hors sujet... Le but de cette question bonus n'était pas de trouver la manière la plus rapide de clôner une Array, mais de trouver un exemple retors utilisant des fonctions sur d'autres fonctions.

Ici, la fonction f prend en paramètre une fonction et fera en sorte que cette fonction soit appelée en décalant les arguments d'un rang vers la droite, le premier argument devenant le contexte d'appel. C'est donc un moyen commode de "déméthodiser" une fonction dans le cas où on doit l'appeler régulièrement avec des contextes d'appels différents. Il existe plusieurs autres variantes dont celle-ci qui sépare passage du contexte et des arguments en deux appels consécutifs:

Code:

---

1 2	var superbind = Function.bind.bind(Function.bind); superbind([].slice)([1,2,3,4])(1,3) // [2, 3]

---

Pour une utilisation pratique de ce genre de fonctions, par exemple pour de la curryfication, le code est plus verbeux et plus explicite, donc inexorablement moins fun.

Sympa ce test sur les fonctions.
J'espère qu'il y en aura d'autres ;)

arf ... 7/10 :calim2:

bon test mais j'aurais des questions/precisions/corrections ...



Q8 : il ne suffit pas de creer une fonction dans une fonction pour avoir une closure ... la fonction principale doit renvoyer la fonction interne comme resultat ... non ?
ou alors la fonction interne doit etre appelé dans la fonction principale.

ex :

Code:

---

1 2 3 4 5 6 7 8 9

function stockEtProtege(){ var valeurPrive = "coucou"; return function(){ return valeurPrive; }; } valeur = stockEtProtege(); console.log(valeur());

---

mais ceci n'est pas une closure, ex :

Code:

---

1 2 3 4 5

function a(){ function b(){ } }

---

Q9 : faudrait peut etre etre + precis dans la réponse ? (meme si l'explication sous la réponse donne toutes les infos)

Q8: Si je m'en tiens à la définition MDN:

Citation:

---

Les fermetures, ou closures en anglais, sont des fonctions qui utilisent des variables libres.

---

On pourrait donc extrapoler en disant que toute fonction en JavaScript est une closure, dans le sens où elle a cette propriété de pouvoir se référer à des variables de portée supérieure, non locales donc libres. Bien sûr ce n'est pas le sens habituel qu'on leur prête : quand on mentionne les closures, c'est généralement dans le but d'utiliser leurs propriétés (d'où la question qui suit, à quoi servent les closures). Retourner la fonction interne est un cas d'utilisation possible, mais pas le seul (voir les différents exemples sur la page MDN). Dans tous les cas, aucun doute sur la réponse possible.

Q9: la réponse est volontairement floue pour couvrir tous les cas d'utilisation possibles des closures. Je ne peux pas être exhaustif et précis à la fois. Les compléments d'infos dans la réponse après avoir fini le quiz sont là pour apporter ces précisions.

5/10
bon comme ça fait un bail que je n'ai pas pratiqué le JS, j'estime que je ne m'en sors pas trop mal :)

Hum 2/10...:mouarf: