Discussion :

[Atatorus]

Bonjour,

j'ai une petite question concernant la syntaxe Java : pourquoi le langage n'a-t-il pas de paramètres nommés ? Ceci rendrait la lecture du code plus compréhensible. Par exemple, si une méthode possède cette signature :

Code :

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

void methode(int min, int max, int alertMin, int alertMax, boolean stop)

L'appel à cette méthode ressemblera à ça :

Code :

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

methode(10, 100, 15, 95, true)

ce qui est moins parlant que

Code :

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

methode(min=10, max=100, alertMin=15, alertMax=95, stop=true)

Au niveau du code compilé, ça ne change rien, et je ne pense pas que ça complique beaucoup les choses pour le compilateur. Sans rendre cette syntaxe parfois lourde obligatoire à chaque appel, elle permettrait de rendre le code plus compréhensible dans le cas des méthodes avec de nombreux paramètres. On pourrait même imaginer indiquer des valeurs par défauts pour des paramètres absents lors de l'appel, par exemple :

Code :

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

void methode(int min, int max, int alertMin = 15, int alertMax = max - 5, stop = true)

Je ne suis certainement pas le premier à penser à une telle syntaxe, qui existe déjà dans d'autres langages. Si elle n'existe pas dans Java, c'est qu'il doit y avoir une bonne raison, mais je ne vois pas laquelle, peut être est-elle liée à la réflexion ?

[Rei Ichido]

Personnellement je trouve ça surtout lourd, comme écriture. Quand on programme uniquement avec des types primitifs, ça peut être une solution pour éviter de s'emmêler les pinceaux entre N arguments ; mais en objet, on peut toujours se restreindre à quelques arguments bien nommés. Du coup l'intérêt est (à mon sens) très très limité, et ne contrebalance pas l'inconvénient de lourdeur ajoutée au code.

[thelvin]

Plutôt que de nous forcer à mettre des millions de trucs sur la même ligne, pourquoi ne pas faire :

Code :

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

1
2
3
4
5
6
int min = 10;
int max = 100;
int alertMin = 15;
int alertMax = 95;
boolean stop = true;
methode(min, max, alertMin, alertMax, stop);

?

Il est tout de même assez rare que ces valeurs magiques au milieu du code aient une quelconque raison d'être.

(Note : pour les valeurs par défaut je suis assez d'accord, à la mode C++. C'est plus pratique que de surcharger la méthode soixante fois.)

[adiGuba]

Salut,


Les paramètres nommés ne serait pas bien complexe à implémenter en effet, mais cela implique plusieurs contraintes en rapport avec les spécificités du langage :

• Dans un premier temps il faudrait stocker le nom des paramètres dans les fichiers *.class (ce qui n'est pas le cas actuellement).
  En effet afin que le compilateur puisse mapper correctement les paramètres selon leurs nom, il a besoin de connaitre ces noms justement.
• Cela implique également que le nom des paramètres, qui étaient jusqu'alors complètement insignifiant, deviendrait alors très important pour la résolution de méthode. Et le simple fait de renommer un paramètre pourrait engendrer des incompatibilités !
• Enfin il y aurait une grosse cassure, entre les nouveaux fichiers *.class contenant le nom de paramètres, et les anciens qui ne les possèdent pas. Ainsi il serait logiquement impossible d'utiliser les paramètres nommés avec une librairie qui n'aurait pas été compilée avec la bonne version. Or une très grande majorité des librairies tierces sont compilé sur un JDK assez anciens pour toucher plus de monde...

Bref ce serait simple à faire, mais cela apporterait beaucoup de contrainte.



Si tu compares avec le C++, il faut bien comprendre que les deux langages utilisent des mécanismes de résolution de méthode très différents, qui impliquent divers contrainte inhérente aux solutions choisis.




Le problème est un peu le même avec les valeurs par défaut, qui peut poser problème avec la surcharge de méthode. D'ailleurs ce n'est peut-être pas pour rien que la surcharge de méthode est très limité en C++ : on ne peut pas surcharger les méthodes héritées (cela les cachent automatiquement).

En fait la surcharge "fait chier" car cela complique énormément la résolution de méthode.

Déjà la surcharge est source d'ambiguïté : si on joue avec des types proches, cela peut générer des erreurs de résolution des méthodes.
Si on cumule à cela les "valeurs par défaut", on augmente grandement le risque d'ambiguïtés, et donc d'erreurs...

Le gros problème c'est qu'en Java on a une édition des liens dynamiques à l'exécution. Ainsi contrairement aux C++ une partie de ces erreurs ne serait plus limités à la compilation mais à l'exécution.

En gros tu pourrais avoir des cas où ton code compilerait normalement, mais où l'exécution engendrerait une erreur de résolution de méthode

En fait pour réellement supporter les valeurs par défaut tout en produisant un code typesafe, il faudrait revoir complètement les mécanismes de résolution de méthode...

En particulier, il faudrait distinguer les méthodes uniquement sur leurs noms et non plus via leurs noms+types des paramètres.

Bref tout cela semble anodin, mais pas forcément simple à mettre en place...


a++

[Atatorus]

Hum, je m'attendais à ce que mon idée pose quelques problèmes, mais pas autant que ça. Il est vrai que j'avais oublié la rétro compatibilité de Java.

Merci pour ces explications !

[adiGuba]

Attention je n'ai pas dit que c'était impossible, mais simplement que ce n'est pas si "simple". D'ailleurs cela a été intégré dans C# 4.0, mais on y retrouve la mêmes problèmes :

• Versioning Issues With Optional Arguments
• More Versioning Fun With Optional Arguments

a++

[bouye]

Salut,

• Dans un premier temps il faudrait stocker le nom des paramètres dans les fichiers *.class [...].
• [...]
• Enfin il y aurait une grosse cassure, entre les nouveaux fichiers *.class contenant le nom de paramètres, et les anciens qui ne les possèdent pas. [...]

Bien que je ne vois pas l’intérêt des paramétres nommés en tant que tel (on peut faire quelques chose de manière similaire avec une Map ou en passant un objet contenant ces membres-la en paramètre de la méthode), et ne connaissant pas du tout comment cela est implémenté en C#, Je ne vois pas en quoi il peut être nécessaire de modifier les fichiers class pour arriver a un tel résultat.

Cela pourrait être une étape de compilation similaire a ce qui est actuellement utilisé pour les Generics ou le foreach : du sucre syntaxique qui ne nécessiterai que des passes supplémentaires du compilateur sans pour autant résulter en un byte code différent..

[adiGuba]

Salut,

et ne connaissant pas du tout comment cela est implémenté en C#, Je ne vois pas en quoi il peut être nécessaire de modifier les fichiers class pour arriver a un tel résultat.

Je me base sur les discussions qu'il y a eu sur la mailing-list du projet Coin lors des propositions de nouvelle syntaxe.

Les fichiers class doivent être modifiés pour contenir le nom des paramètres, ce qui n'est pas le cas actuellement. Sans cette information dans les fichiers *.class le compilateur ne peut pas connaitre le nom des paramètres, et donc il ne peut pas compiler le code...


Le second problème vient du fait qu'il n'y a jamais eu de règle stricte pour les nom de paramètres, et que chaque implémentation de l'API peut utiliser ses propres noms, ce qui aboutit à créer de nouvelles incompatibilités.

En .NET le problème est moindre puisque les paramètres nommés existait dès la version 1.0 en VB.NET. Du coup je suppose que le nom des paramètres devait faire partie de la signature de la méthode...

Cela pourrait être une étape de compilation similaire a ce qui est actuellement utilisé pour les Generics ou le foreach : du sucre syntaxique qui ne nécessiterai que des passes supplémentaires du compilateur sans pour autant résulter en un byte code différent..

C'est exactement ce que c'est en C#/C++ : le compilateur remplace l'appel par un appel "standard".

Mais encore une fois pour cela il faut connaitre le nom des paramètres...



Si on rajoute à cela les problèmes d'évolutions que cela pose, ce n'est pas forcément une si bonne idée d'implémenter cela. En fait cela s'adapte très bien à des langages dynamiques sans surcharge de méthode (comme le PHP) ou à des langages compilés en natif (comme le C++) en impliquant une recompilation totale de l'application. Mais avec des langages à liaisons tardives comme Java/C# on peut avoir des effets indésirables qui aboutissent à des erreurs à l'exécution


a++