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.

Alors que je pense aux classes utilitaires qui seraient utilisables au sein du langage que je développe, je me suis heurté à un problème concernant les collisions de noms de méthode.

Imaginons dans un premier temps les interfaces suivantes :

On peux imaginer une application qui viens simuler un animal tombe sur un aliment.

On commence par implémenter deux classes concrètes pour Aliment :

C’est alors que ça deviens intéressant. Avec le langage Java, j’avais quelques habitudes pour distinguer les implémentations particulières afin d’éviter par exemple de créer un BufferedInputStream alors qu’on m’en donne déjà un lorsque je demande un InputStream.

Je décide alors d’utiliser ce comportement pour implémenter un lapin :

Le schéma en soit ne choquerait pas directement un développeur Java qui aurait déjà observé le code de certains constructeurs de quelques classes Java. Pourtant cela me pose un problème conséquent sur la détermination de la méthode à appeler.

Imaginons ce bout de code suivant :

A la ligne 9, je n’ai pas de souci pour déterminer la méthode appelée. « pommeDeTerre » n’est pas instance de la classe « Carotte » et donc par élimination il n’y a pas d’autres choix que d’appeler « Lapin#regarder(aliment : Aliment):VIDE »
Par contre c’est une toute autre histoire à la ligne 10 où là j’ai le choix entre « Lapin#regarder(aliment : Aliment):VIDE » et « Lapin#regarder(carotte : Carotte):VIDE ». En effet, les deux sont éligibles car « carotte » est bien une instance de « Carotte » qui hérite de « Aliment ». On peux dire qu’on prends alors la méthode qui utiliserait le paramètre le plus éloigné dans l’arbre d’héritage, mais alors dans le cas particulier d’une classe générique, que ce passe-t-il si les deux paramètres attendent la même classe ?

La solution la plus simple à mon sens est d’interdire la nomination identique de plusieurs méthodes au sein d’une même classe comme c’est le cas en PHP, mais alors il y aurait à perdre quelques fonctionnalités assez utiles de Java.

Je me suis lancé dans la conception d’un langage objet qui sera ensuite compilé dans d’autres langages au même titre que Dart et CoffeeScript qui sont compilés en Javascript.

Plusieurs problèmes se posent à la création d’un langage :

L’outil de compilation :

Plusieurs choix s’offrent à moi. Je pourrais tout simplement créer un compilateur avec le couple lex/yacc qui me donnerai un langage cible connu et en rester là. Cependant cela ne me satisfait pas tellement car j’aimerais fournir plusieurs langages cibles afin d’être utilisable par une jvm, un moteur javascript ou un interpréteur PHP. Créer plusieurs compilateurs pour ces différents outils semble difficile, et c’est d’ailleurs le cas. Mon choix s’oriente vers une compilation en deux temps. D’abord un lexxer/parser sera écrit (je ne sais pas encore avec quel outil mais surement un existant), pour produire une série de fichiers xml pré-compilés. Un peu comme le bytecode de Java. Par la suite, une transformation XSL permettra de générer un code dans le langage cible.
Cette compilation en deux temps a quelques avantages. Il permet à un nouveau langage de voir le jour, de générer des fichiers XML validé par les mêmes outils de validations (je pense à des Schémas XSD) pour réutiliser les mêmes transformations XSL afin de produire le code souhaité.

L’environnement :

Mon objectif est de compiler le même langage vers du javascript, java (ou bytecode) ou même PHP. Mais ces derniers langages n’ont que peu de choses en commun. Il n’existe pas de Socket avec IE7 pour être utilisé en Javascript, PHP ne sais pas afficher d’éléments graphiques, l’accessibilité des bases de données est très limitée en javascript (un peu moins en ce moment grâce à Node.js). Aussi il faut prévoir les outils nécessaires afin d’accéder à ces éléments graphiques et prendre en compte leur inaccessibilité.

Le langage :

Le langage lui même est un problème. Il faut prévoir une grammaire suffisamment robuste pour implémenter toutes les fonctionnalités. On notera par exemple qu’il est impossible en javascript de s’assurer du typage des paramètres d’une fonction de façon native.