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.