54 lines
5.5 KiB
Markdown
54 lines
5.5 KiB
Markdown
# 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` ?
|