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 !

[herve91]

L'application produite par l'élève est mono "classe" ?
Si la réponse est non, j'en reviens à ma question : comment appeler une méthode d'une autre classe ?

[dinobogan]

Quitte à ne pas faire d'objet, inutile de brouiller les élèves avec le nom de la classe. autant adopter une écriture C.

[Drannor]

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.

Volonté de nos encadrants de se baser sur du java. Ils veulent que si l'élève souhaite continuer à programmer, il retrouve ses repères facilement. De plus, on n'invente pas réellement un langage, on simplifie juste Java en le limitant dans le cadre des interventions de l'enseignant.

Pour plus d'information voir sujet dans mon pote précédent.

[dinobogan]

Volonté de nos encadrants de se baser sur du java. Ils veulent que si l'élève souhaite continue à programmer, il retrouve ses repères facilement. De plus, on n'invente pas réellement un langage, on simplifie juste Java en le limitant dans le cadre des interventions de l'enseignant.

Pour plus d'information voir sujet dans mon pote précédent.

Oui, ok. Ton post est passé juste avant le mien. Je viens de lire le sujet. Effectivement, pas le choix

Et au lieu de se casser la tête, tu pourrais faire dériver toutes les classes produites d'une super classe qui contient les fonctions "simplifiée" :

Code :

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

1
2
3
4
5
6
7
class Super
{
  public static afficher( String s )
  {
    System.out.println( s );
  }
}

Et la classe écrite par le lycéen :

Code :

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

1
2
3
4
5
6
7
Toto
{
  void main()
  {
    afficher( "Hello World" );
  }
}

Puis le code produit juste avant la compilation :

Code :

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

1
2
3
4
5
 
class Toto extends Super
{
...
}

[Drannor]

l'application produite par l'élève est mono "classe" ?

Oui. Il faut comprendre que leur enseignement se fera sous la forme d'un squelette à compléter et de quelque ligne de code à introduire. Ils doivent s'initier au fonctionnement d'un programme avec les appels de fondtions, les retours, les types. Cela toujours dans le cadre de l'enseignement de leurs encadrants.

Quitte à ne pas faire d'objet, inutile de brouiller les élèves avec le nom de la classe. autant adopter une écriture C.

Effectivement mais la demande du client est autre.

Enfin merci de m'avoir répondu sur l'impossibilité de voir le code source par introspection. Je vais me débrouiller autrement

[adiGuba]

Ce que je vois c'est que l'introspection n'est pas la solution.

L'introspection consiste à obtenir des informations sur du bytecode compilé. Toi tu souhaites obtenir des informations contenu dans le code source...


Peut-être qu'un parseur comme javacc serait plus adéquate...


a++

[Drannor]

Merci, je ne connaissais pas cette techno, je vais me pencher dessus.

[herve91]

Et au lieu de se casser la tête, tu pourrais faire dériver toutes les classes produites d'une super classe qui contient les fonctions "simplifiée" :

Pour compléter :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class Toto extends Super
{
  void main()
  {
    afficher( "Hello World" );
  }
 
  public static void main(String[] args) {
     new Toto().main();
  }
}

et les méthodes de Super n'ont pas besoin d'être statiques.

[Drannor]

Merci pour ces superbes idées, on va se pencher dessus et voir l'avis de nos encadrants.