Merci a Nicolas et Zeljko pour leurs commentaires.
(1) declaration de classe dans une methode : je trouve cela tres pratique et
je l'utilise tres souvent principalement pour sous-classer Thread et lancer
des processus de portee locale (je n'ai pas besoin de visibilite sur la
sous-classe a l'exterieur de la methode).
Je ne pensais qu'aux classes explicites, les classes anonymes etant tres utiles. Qqch du genre:
public class Truc {
public int maMethode(int a) {
int z=18;
class Machin() { }
return z+a;
}
}
Je trouve ca "bizarre" et illisible. Mais effectivement, en y regardant de plus pres, ca peut etre utile en raison de la portee. J'aime beaucoup le nom genere "Truc$1Machin". Allez, on retire (1).
(2) Je suis d'accord. Mais il y a pire : le "psuedo-champ statique" class
(ex : StringBuffer.class) qui se confond avec un mot cle ... Comment peut-on
parser ce truc sans tricher ?
Effectivement ;-(
En fait la justification donn� � l'�poque �tait le suivante. le fait d'�crire le truc .class
permettait de ne pas inventer de nouveau mot-cl� r�serv�, "class" existant d�j�.
(3) C'est parfaitement normal : de meme que le if ... else ne constitue qu'une seule instruction. Pourquoi (et surtout comment) en serait-il autrement ?
Certes mais la syntaxe est etonante. Du moins aujourd'dui-maintenant elle m'etonne. (Vu qu'elle vient du C++, ca doit faire presque 15 ans que je l'utilise sans me poser de question)
Ne vire donc pas tout trop vite ...
Ok. Bon, j'ai ajoute les modifs necessaires a mon analyseur pour prendre en compte ces "etrangetes". La prochaine version d'Alma (0.40) sera la premiere a parser le jdk1.4.2 sans message d'erreur (mais peut-etre pas sans erreur).
PS1: j'angoisse deja a l'idee d'ajouter le support pour les templates.
Oui, bonne chance :)) Surtout l'algo d'inf�rence de types, il � l'air coton.
PS2: je reve toujours du langage "simple", non ambigu et facile a parser en une passe. Pourquoi faut-il toujours tout complique ?
Je suis pas d'accord, �tre oblig� d'�crire les d�clarations puis les d�finitions pour que
le parser s'y retrouve, je trouve cela assez bourrant.
Les langages doivent �voluer avec les machines, elles ont maintenant assez de
RAM pour qu'on puisse garder la structure en m�moire et faire plusieurs passes.
En plus �a s�pare les diff�rentes phases au niveau du compilateur, je trouve �a pas trops mal.
Le gros probl�me est pourquoi il n'y a pas d'interface claire au compilateur
qui permettrait de manipuler le code Java sous forme d'objet, ce qui �viterait
de r�-inventer la roue � chaque fois. (j'attend beaucoup de la JSR 199).
GuillaumeRemi
