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

:salut:

Les fonctions sont un des éléments les plus intéressants du langage JavaScript, mais beaucoup de leurs subtilités restent méconnues. Afin de mesurer vos connaissances et de vous faire découvrir de nouvelles manières d'utiliser les fonctions, un nouveau quiz JavaScript dédié aux fonctions vient d'être publié !

:fleche: Quiz: Usage avancé des fonctions

Le quiz est de niveau difficile, donc pas de panique si vous n'avez pas la moyenne :P Et merci de ne pas indiquer des éléments de réponse dans vos commentaires. http://www.developpez.net/forums/ima.../icon_wink.gif

Pour les plus chevronnés d'entre vous, je vous propose une onzième question pas piquée des vers. Etant donné son haut niveau d'inintelligibilité, je vous laisse vous échanger des pistes de réflexion publiquement dans les commentaires de ce topic.

QUESTION BONUS
11. A votre avis, à quoi sert la fonction suivante ?

Code:

---

var f = Function.bind.bind(Function.call);

---

a) à chaîner des fonctions en gardant toujours le même contexte d'appel
b) à transformer une méthode en fonction classique où l'instance est passée en argument
c) à modifier la fonction bind pour qu'elle exécute les fonctions sur lesquelles on l'appelle
d) à faire s'arracher les cheveux aux collègues


Merci à NoSmoking, SpaceFrog et vermine pour la relecture du quiz.


Participez également à nos autres quizz :
:fleche: Les quizz JavaScript.
:fleche: Tous les quizz de Developpez.com dont certains portent sur le CSS, HTML ou PHP.

7/10, c'est mieux que mon score sur le DOM :aie: !
Sympathique ce petit test, j'aurais dû le faire demain matin après le café plutôt qu'en fin de journée, mais ma curiosité a eu le dessus :D

Pour la question BONUS, je dirais que c'est une sorte de wrapper qui évite de taper maFonction.call :

Code:

---

1 2 3 4 5

function maFonction() { console.log(this.nom); }   maFonction.call({nom: 'Marty'}); // Marty

---

A la place, suffit donc de :

Code:

---

1 2	var f = Function.bind.bind(Function.call); f(maFonction)({nom: 'Marty'});

---

Mais à quoi ça peut servir à part donner un contexte d'exécution à maFonction ?
Je trouve qu'utiliser maFonction.call(context) est plus clair.

9/10 mais la réponse à la question 9 est une réponse par défaut :mrgreen:
@Kaamo: sans tester ? :P

Ah et merci, ça fait du bien

Bien oui sans tester :mrgreen:
J'ai échoué à la 5 et à la 8 & 9 sur les closures. Parce qu'utiliser une closure, c'est cacher la valeur de certaines variables aux utilisateurs selon moi. ça ne peut pas marcher aussi comme réponse ? :mrgreen:

Bravo!
La valeur d'une simple variable locale dans une fonction est aussi cachée pour l'utilisateur, non ?

Oui c'est inaccessible via le scope global.
Je trouve que la réponse 3) de la question 9 pourrait aussi bien être une bonne réponse. En définissant des variables dans une closure, on rend inaccessible leur manipulation des utilisateurs mais pas des développeurs bien sûr

Bin même en tant que developpeur, à part modifier le source de la fonction oeuf corse ça me semble difficile et dans ce cas on peut tout faire :) donc je dirais que non

8/10 ! Moi aussi j’ai été plus inspiré que le quiz sur le DOM

J’ai eu une hésitation sur la première question et me suis, du coup, planter sur la dernière
Du coup je me pose la question, à savoir si cela a été normalisé par l’ECMA car il me semble qu’il y a encore peu cela avait de comportement diffèrent selon les environnements Javascript

J'ai justement changé la proposition C de la Q9 avant publication pour lever complètement le doute. Le fait qu'une variable soit dans une portée locale ne permet pas de cacher sa valeur, elles pourront toujours être retrouvées par l'utilisateur final. Ce n'est pas beaucoup plus compliqué de mettre un breakpoint que de fouiller les variables globales. Et ce n'est pas le rôle des closures de toute manière.

Pour la Q10 la réponse peut être retrouvée dans les spécifications ECMA-262.

Concernant la question bonus, Kaamo a compris le principe général. Quelqu'un a une idée de à quoi cela pourrait servir ?

J'ai failli mettre la Réponse 4 pour la Question 10. En effet, le résultat peut-être, légèrement, différent selon si la fonction est native ou non :P

Citation:

---

Envoyé par SylvainPV

Quelqu'un a une idée de à quoi cela pourrait servir ?

---

Mis à part ce qu'a écrit Kaamo c'est à dire de passer d'un appel de méthode à un appel de fonction :
object.method(...) ==> methodFn(object, ...) avec methodFn = F(object.method)
J'avais écrit une bétise tout à l'heure qui pourrait être une conséquence de ce type d'écriture et qui consisterait à se passer de 'this' pour l'écriture de nouvelle fonctions (mais personne ne veut refaire du C, surtout sans pointeur :D).
Ce qui me chagrine, c'est que j'ai lu un truc quelque part qui parlait de ça mais j'ai complétement oublié :? peut-être en rapport avec la programmation fonctionnelle ? ou alzheimer ?
Peu importe, j'attends avec impatience les propositions de réponses ! +1 pour la question

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

---

C'est un des usages possibles, il y en a d'autres :)

Ca peut servir a rendre accessibles des fonctions natives plus facilement :
var f = Function.bind.bind(Function.call);
var map = f(Array.prototype.map);

map est directement utilisable sous forme de fonction plutôt que d'appeler a chaque fois Array.prototype.map.call(.....).
Par contre je pense que c'est moins efficace côté perf (à cause du bind).

Je ne sais pas à quoi servent les clotures au final, je les utilise essentiellement pour émuler le mot-clef 'static' du C, en gros pour avoir des variables rémanentes, ou des fonctions, qui ne polluent pas la portée parente. Bien qu'en C, elles soient définies dans la portée d'utilisation. J'ai souvent été étonné de la confusion entre variables privées et static d'ailleurs.

@lysandro: tu viens déjà de lister deux utilisations possibles :) Un article dédié aux fermetures va être publié prochainement, ce sera l'occasion de faire le tour du sujet.

9/10. pas mal :)

Pour ma défence (parcequ'on est jamais content ^^) : La question 6 aurait pu être mieux reformulée :P

Bravo pour ce quizz ! J'attends les suivants...

Oh, je l'ai pourtant reformulée une paire de fois celle-là. Qu'est-ce qui ne t'a pas paru clair ?

C'est juste la phrase "dans le code d'une fonction A" que j'ai mal compris. Je ne pensais pas que tu voulais parler du "corps de la fonction A".

:pleure: pas en forme ce matin Votre score : 7 / 10 (pas terrible pour un relecteur)

Citation:

---

Envoyé par Kaamo

Mais à quoi ça peut servir à part donner un contexte d'exécution à maFonction ?
Je trouve qu'utiliser maFonction.call(context) est plus clair.

---

si tu n'as qu'une fois l'écriture à faire oui mais on peut étendre le raccourci à plusieurs fonctions et aller jusqu'à créer des "pseudoMACRO"

Code:

---

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

var personne = { nom : 'Mac Fly', prenom : 'Marty' };   var f = Function.bind.bind(Function.call);   function voirNom() { console.log(this.prenom +' ' +this.nom); } function changeNom() { this.nom = arguments[0] || 'unknow'; console.log(this.prenom +' ' +this.nom); } // pseudo MACRO var fct_voir = f( voirNom); var fct_change = f( changeNom);

---

on pourra donc écrire

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// version de 'base' voirNom.call (personne); // Mac Fly changeNom.call( personne, 'En Vacances'); // Marty En Vacances   // version 'bind.bind' f( voirNom)( personne); f( changeNom)( personne, 'En Vacances');   // version 'macro' fct_voir ( personne); fct_change( personne, 'En Vacances');

---

bon d'accord il y a d'autres façon de gérer cela.

Hum, test sympathique, néanmoins, fort dommage d'y voir tant de choses non-valides en strict mode...

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: