Je parcourais récemment les origines du Javascript pour me perfectionner dans ce langage et comprendre un peu plus ce qu’il s’est passé avant que je ne commence à développer des sites web (la guerre entre netscape, IE et le W3C). C’est alors que je suis tombé sur l’avenir du langage, c’est à dire ECMAScript 6 « Harmony » de nos jours.

J’y ai trouvé ce que je pense être l’une des idées les plus mal introduites dans un langage informatique, les générateurs.

Les générateurs n’ont pas été inventés pour Javascript mais existent déjà en PHP 5.5. Il faut alors apprendre ce pourquoi ils ont été réalisés et comment ils ont été implémentés pour comprendre ce qui a été fait dans ECMAScript 6.

En PHP 5.5 nous pouvons maintenant nous abstenir de l’instruction « return » et utiliser l’instruction « yield ». La fonction retourne alors un générateur et non une valeur.
Un générateur est un objet dont l’idée principale est de fournir une méthode « next » pour accéder à des valeurs successives rendues disponibles par l’instruction « yield ».

Un exemple concret serait l’extraction des différents champs d’une date à partir d’un timestamp. Il existe des fonctions natives pour cela mais imaginons que nous n’y avons pas accès.
On souhaite alors retrouver l’année, le mois, le jour du mois, le jour dans l’année, le jour de la semaine, l’heure, les minutes et secondes … n’importe quelle information commune sur la date. Je vais me restreindre aux données horaires pour diminuer la taille des codes présentés.
Si je me retrouve dans l’incapacité de créer un générateur, en PHP nous aurions du créer cette fonction :

Ici nous allouons un tableau de résultats avant de le retourner d’un seul coup. Il y a ici une consommation de mémoire induite par le stockage des résultats intermédiaires. Pourtant nous devrions être capable de les consommer sans placer en cache les différents résultats. C’est l’idée principale des générateurs. Sur des applications plus complexes, ils permettent l’accessibilité de résultats intermédiaires et donc une réduction de la consommation mémoire avec peu d’efforts.

Avec le mot clé yield, le code si dessus deviens le suivant :

Le code est très semblable et peux être compris de la même façon. La différence règne dans la consommation mémoire. En effet le moteur PHP ne retourne pas une valeur à l’exécution de cette « fonction » mais un générateur qui n’est autre qu’un itérateur sur les résultats indiqués par le mot clé « yield ». Entre chaque itération, la fonction est reprise au même endroit jusqu’à atteindre le prochain résultat. On arrive aussi à produire une fermeture sur le champ $timestamp car il reste accessible et modifiable avec les itérations successives du générateur. C’est un ajout puissant dans PHP car hormis le contexte d’un objet ou de paramètres, il n’existe pas de fermeture en PHP.

Maintenant il faut comprendre aussi ce qu’un générateur n’est pas fait pour l’itération simple d’une structure quelle qui soit. Par exemple si on souhaite itérer sur un tableau, on préfèrera ce code …

… à ce code …

En javascript, le problème est différent car nous disposons déjà des fermetures et la traduction d’un générateur en code javascript est simple.

Avec ECMAScript 6, deux nouveaux mots clés sont introduits dans le langage, « function* » (l’étoile est importante) et « yield ». Le comportement est similaire avec l’implémentation de PHP aussi pour implémenter le générateur PHP en JS, nous pourrons écrire ceci :

Cependant ceci est un sucre syntaxique repris de PHP pour en réalité représenter ce code :

Le code est tout aussi fonctionnel, clair et certes plus verbeux. Nous n’avons qu’un gain de verbosité (et encore ce n’est qu’un switch+case) à ce qui peux être écrit tout aussi simplement.

Le problème est aussi dans la notation de ce générateur, et c’est un reproche que je fais aussi à l’implémentation PHP, qui est identifié par le mot clé « function* ». Pour un débutant sur le langage, cette notation porte fortement à confusion. Si il veux alors comprendre pleinement la notion des fonctions, il ne doit jamais croiser de générateur ou bien il peux alors se retrouver dans la confusion d’un sucre syntaxique inutile.

ECMAScript 6 donne de bonnes idées avec le retour des itérateurs, les maps et cette nouvelle notion de promesses mais rajoute un sujet de confusion à travers les générateurs.