Discussion :

[Drannor]

Bonjour,

J'essaye actuellement à partir de l'introspection d'afficher le code source d'une classe, mais je bloque sur le code contenu dans la méthode.

Y'a t'il un moyen d'afficher le code contenu ?

Merci d'avance

[adiGuba]

Salut,

Y'a t'il un moyen d'afficher le code contenu ?

Non... pas en standard.

Tu peux peut-être utilisé un décompilateur... mais j'ai du mal à comprendre l'intérêt de cela

a++

[Alp]

J'aimerais également connaître tes motivations.

J'ai beau réfléchir et je ne vois rien qui motiverait cela... Avoir des informations, oui, mais le code contenu dans la fonction... Je ne vois vraiment pas.

[Drannor]

Dans le cadre d'un projet universitaire, je développe avec des camarades de cours une application eclipse rcp pour que des lycéens apprennent la programmation. Ils disposent d'un macro langage basé sur Java (exemple afficher = System.out.println). cette idée est voulue pour ne pas noyer l'élève dans la compléxité du langage. Il n'a donc pas à faire d'import où à se préoccuper des static et autres ...

Il peuvent bien entendu développer leur class :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Toto {
 
   void mafonction(){
      afficher("hello world !");
   }
 
   void main(){
     mafontion();
   ]
}

Pour compiler ces classes, on passe par une phase de traduction lors de laquelle ont remplace les macros par leur traduction mais pour ce simplifier la vie afin de connaitre le nom des méthodes qu'il créait ainsi que la signature qu'elles ont et savoir si c'est un appel de fonction ou vraiment une déclaration de fonction et ainsi pouvoir rajouter si besoin les mots clefs public static, on souhaite utiliser l'introspection.

Car comme ils n'ont pas de notion objet, ils n'ont pas à instancier leur classe et donc toutes les méthodes créaient doivent être static.

Ainsi le code au dessus devient après traduction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public class Toto {
 
   public static void mafonction(){
      System.out.println("hello world !");
   }
 
   public static void main(){
     mafontion();
   ]
}

On a eu l'idée d'ajouter au début du code source que l'élève tente de compiler le mot class et de passer une première fois celle-ci à la compilation (les méthodes étant alors automatiquement classé comme public si je ne m'abuse) dans le but de réécrire le code source en y ajoutant les mots clefs avant de la refaire compiler pour qu'il puisse l'éxécuter.

L'introspection nous permet de rapidement identifier la déclaration des méthodes et si je souhaitais récupérais le code source d'un méthode c'était pour qu'au moment de l'introspection, je puisse effectuer la recopie à la volet et ajouter les mots clefs souhaité.

[herve91]

Je ne comprends pas l'intérêt des deux phases de compilation.
C'est un problème de traduction de code source maison vers un code source Java.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<déclaration-de-méthode>

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public static <déclaration-de-méthode>

Par contre, comment on fait, à partir de la classe Toto, pour appeler une méthode (statique) définie dans la classe Titi ?
NB : masquer le fait que Java soit un langage objet est-il pédagogiquement une bonne chose ?

[Drannor]

La première compilation nous permet d'obtenir un .class qu'on va parcourir pour identifier la création des fonctions de l'élève et ajouter ce qu'il faut. Et vu qu'il est aussi possible de connaître tous les champs de la classe, on peut en même temps réécrire le fichier java qui sera recompilé.

La seconde compilation est en faite la vraie compilation dont le résultat apparaitra à l'écran.

Pour l'appel de fonction d'une classe à une autre, cela ne se fera jamais.

Pour résumer :

L'élève souhaite compiler son programme, il clique sur le bouton de compilation.
On le traduit du macro langage au java, on le compile en sous main pour identifier les méthodes aux quels on doit ajouter des informations, on réecrit un fichier java qu'on fait compiler et on renvoi le résultat dans la console de notre application RCP.

Pour le coté pédagogique :
C'est la volonté des enseignants des lycées de ne pas abordé l'objet car ils n'ont que quatre séance de trois heures pour cette initiation à la programmation. De plus, même si les enseignants ont des notions d'informatique et de programmation, ils sont pour la plupart habitué au pascal et donc ne sont pas former avec la concept objet. Dernier point l'outil est là pour à la fois initié mais pour aussi aider l'encadrant dans sa spécialité, il ne peut pas réellement donné de cours d'informatique car il n'est pas accrédité pour. L'initiation doit donc se faire comme si c'était dans le cadre de l'utilisation d'un logiciel.

Voir le sujet : http://deptinfo.unice.fr/~huet/M1INF...R/mongiat.html

[dinobogan]

Je ne comprends pas l'intérêt des deux phases de compilation.
C'est un problème de traduction de code source maison vers un code source Java.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<déclaration-de-méthode>

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public static <déclaration-de-méthode>

Par contre, comment on fait, à partir de la classe Toto, pour appeler une méthode (statique) définie dans la classe Titi ?

C'est là que la double compilation a sa limite

NB : masquer le fait que Java soit un langage objet est-il pédagogiquement une bonne chose ?

Tant qu'il invente un nom pour son langage, différente de Java, pourquoi pas ;-)


Sinon, il faut vraiment passer par une vraie grammaire pour votre langage. La double compilation est clairement une très mauvaise idée : il y aura forcément des erreurs sur la première compilation.
La grammaire devra générer du Java à partir d'un source de votre langage, restera plus qu'à compiler.

Mais question : quitte à leur apprendre la programmation fonctionnelle, pourquoi ne pas passer par un vrai langage fonctionnel, éprouvé, et que ces lycéens pourront réutiliser à leur guise ? car inventer un langage, c'est marrant, mais il faut que ce soit utilisable. Limiter au maximum les bugs implique beaucoup de temps.
Bon courage !