5.5 KiB
Notes sur les commentaires de Clément
1 - Recherche du titre
J'ai appris qu'il fallait notifier le responsable des stages si le titre du Rapport devait être différent de celui du Stage. Cela me semble adéquat, le titre original étant « Revisiting Contextual Equivalences for Process Algebras ». Je n'ai étudié que partie du sujet, le Featherweight Java.
- Comparaison sémantique de programmes Featherweight Java (je ne suis pas sûr d'avoir encore complètement compris le sens du mot « sémantique »).
- Définition d'un préordre sur les programmes Featherweight Java
- Équivalences entre programmes orientés objets
4 - Pourquoi le paramètre k
Je voulais juste indiquer que les expressions à trous n'étaient pas toutes marquées h, mais en incluant toutes les déclinaisons.
4 - Le titre de 2.2
Est-ce que le nouveau titre fonctionne ?
4 - Définition appel static
Est-ce plus clair maintenant ?
5 - Incompréhension sur null
Je n'ai pas vraiment compris l'incompréhension, je traiterai cette partie plus tard, en voyant si elle me sert ou pas.
6 - Sur la définition des trous dégénérés
Le contenu de cette section n'est pas très rigoureux. C'est une sorte de présentation des différentes choses que j'ai éssayé avant d'en arriver à la définition des test interfaces. Elle a plutôt pour but d'indiquer à læ lecteur·ice pourquoi j'ai été ammené à considérer uniquement les class tables, et que j'ai ajouté des restriction sur les champs/méthodes accessibles. De plus, ais-je vraiment le temps de faire un théorème. Il y a d'autres cas différents en plus, parce qu des objets infinis ne pouvant pas être instanciés complètement, ils ne peuvent pas discriminer deux class tables.
7 - Problème des class tables qui ne pourraient pas être comparées.
Je l'ai mal formulé dans le document, mais le problème est justement que ces classes seraient vues équivalentes, sans jamais être en pratique vraiment comparées (universalité du vide).
8 - Sauf éventuellement Object
Le éventuellement réferrait à l'utilisation qui est éventuelle. Si la classe Object n'est pas utilisée, la règle n'impose rien.
8 - Ordre des définitions
Les différentes règles supplémentaires font à mon avis partie de la définition de la grammaire des test interface, c'est pour cela que ne voulais pas intercaler la définition de l'opérateur d'implémentation. L'explication informelle du sens des règles explique déjà leur sens vis-à-vis des class tables. J'ai rajouté une phrase, à voir si vous pensez si ça suffit.
10 - On suppose toujours que A est bien typé
Et bien, certaines des class tables que l'on manipule ne sont pas typées par elles-même, c'est le cas des class tables supplémentaires que l'on utilise pour les tests, que l'on concatène ensuite avec la class table testée pour obtenir notre environnement d'execution. Le «A OK» fait référence au typage des class défini dans le papier original. Du point de vue formel, une class table est un ensemble de classes, et une classe est rarement typée par elle-même. J'ai ajouté cette phrase, parce que pendant la preuve, j'ai eu besoin d'utiliser cet argument.
11 - Pourquoi A
Dans tous le document, à partir de la définition des test interfaces, j'ai utilisé comme convention que A représentait la class table testée, c'est à dire celle qui prenait la place de l'interface (d'où son utilisation dans la définition de l'opérateur d'implémentation), et que B représentait la class table de tests, qu'on ajoute afin d'avoir une batterie de tests plus puissante (d'où son utilisation dans la définition des opérateurs). Cela facilite surtout la lecture de la preuve 1, parce que alors les définitions collent aux définitions en place, il n'y a pas de renommage peu lisible à faire.
11 - Sur la notation C'
La notation C' est effectivement plus claire que C0, mais mon problème est que ce n'est pas un nom de classe FJ valide. Est-ce que c'est vraiment génant ?
13 - FJ et les attributs de son propre type
Je ne trouve rien dans le papier qui interdise ça. Tous les noms de classes utilisés n'ont pas de contrainte, les seules contraintes étant que les méthodes return aient bien le type spécifié.
17-18 Noms de classe étranges
La raison de ce choix de noms de classe est le besoin de faire une classe mère au nom simple (comme Bool, List ou Int afin que les types des méthodes soient clairs coté développeur (Pouvoir faire Int meth(Bool x, List l). De là, j'avais deux choix. Ou bien je créais une sous-classe par cas de mon type inductif (On aurait BoolTrue et BoolFalse qui seraient deux filles de Bool et qui donneraient une certaines implémentation à ite), ou alors, faire qu'une des deux soit la classe mère, de façon «invisible» pour le développeur, tant que ce dernier n'utilise pas les noms des classes internes.
Pour la liste, on a encore le problème que une classe ne peut pas avoir un attribut de son propre type est être instanciable. Il faut donc nécessairement une classe mère à la classe représentant Cons, et que cette classe s'appelle List.
19 - Notation C0
J'ai utilisé le nom de classe C0 que je trouve aussi moche. Dans le document original du FJ, la notation était utilisée avec le zéro en subscript. Mais alors, j'ai l'impression que ça casse le mur du formattage FJ de mettre du subscript sur du texte en typewriter font. Peut-être utiliser un autre nom ? Cc ?