Mon blog technique, artistique, d’humeur... Continuer »
Certains raccourcis de codage offerts par JavaFX, qui sont sympas quand ils sont pris séparément, peuvent constituer une combinaison mortelle quand ils sont utilisés ensemble...
JavaFX a fait des efforts pour sembler aussi facile/sympa à utiliser que, disons, JavaScript.
Donc il n'exige pas de vous de toujours déclarer le type des variables, paramètres de fonctions ou variables de retour.
Mais comme c'est un langage typé statiquement, il doit deviner ces types au moment de la compilation ; contrairement aux langages typés dynamiquement qui font ça au moment de l'exécution (c'est plus facile !), et parfois (selon le langage), permet même de changer le type (comme stocker une chaîne dans une variable qui contenait un nombre).
Parfois il échoue à deviner et nous lance une erreur de compilation, demandant d'être plus explicite.
Parfois il échoue piteusement et le compilateur se plante ! (voir mon rapport de bug (en anglais) à Jira / Kenai par example).
Et parfois il peut juste faire un mauvais choix, se retournant contre vous !
Une autre tentative pour paraître facile / agréable à lire est d'omettre le mot-clé return dans les fonctions : JavaFX peut prendre la dernière expression dans la fonction comme valeur de retour.
C'est pas mal dans la méthode create() des CustomNodes, où vous mettez juste la déclaration de Group {}, ou dans une boucle for () créant une séquence, chaque résultat de l'expression créant une entrée dans la séquence.
Cela semble plus étrange quand vous laissez juste un foo; ou même une valeur littérale, et peut être surprenant quand la dernière expression est une affectation !
Cela peut mener à des résultats inattendus, particulièrement quand c'est combiné avec la déduction automatique de type...
J'ai vu ça dans le forum JavaFX (en anglais): un programmeur a déclaré une simple fonction, omettant la valeur de retour comme il ne retournait rien. Mais en fait, il retournait une valeur, sans le savoir... Dans une branche conditionnelle, vers la fin de la fonction, il y avait une dernière affectation, donc le compilateur a pris le type de la valeur assignée comme type de retour de la fonction. Pas un problème majeur, vu que la valeur retournée sera juste ignorée à l'appel.
Mais dans l'autre branche de la condition, il a utilisé un break; pour sortir par anticipation de la boucle dans laquelle il était. Le compilateur était perdu, pensant que break était une expression et il reportait que ce n'était pas compatible avec le type trouvé...
En fait, il était tellement perdu qu'il a généré une erreur interne (d'où le rapport de bug ci-dessus), mais c'est anecdotique, sans cela il aurait donné un message d'erreur un peu cryptique. Je sais que j'ai été désorienté une paire de fois par ces erreur jusqu'à que je pense à donner un type de retour explicite.
Et c'est la morale de l'histoire : ne pas spécifier les type est une facilité que je ne pense pas abandonner, mais pour les raisons ci-dessus et quelques autres, comme la simple lisibilité, je vais essayer de toujours spécifier un type de retour, et même le type des paramètres (donc la signature) des fonctions.
Et vous ?
C'est intéressant d'écrire en français de temps en temps...
You can find the English version of the article at Beware of JavaFX's type inference!.
© PhiLho / PhiLhoSoft | Site principal Design par PhiLho (basé sur un template de ceejay/Carl Galloway) | Motorisé par SerendipityAdmin
Some programming shortcuts offered by JavaFX, nice when taken separately, can be a deadly combination when used together... JavaFX tries hard to look as friendly/easy to use as, say, JavaScript. So it doesn't require you to always declare the type of
Suivi: Juin 20, 11:35
Suivi: Juin 20, 18:21