C'est moins lisible sorti de son contexte. Par contre à l'utilisation et dans le temps c'est beaucoup plus lisible et moins casse gueule.
Il y a deux problèmes, le typage et le contenu des valeurs retournées. Pour le typage, rien n'empêche de typer chaque résultat d'une fonction qui en renvoie plusieurs, et dans ce cas je préfère la syntaxe simple que j'ai présentée au dessus.
Pour le contenu des valeurs, il faut bien voir qu'on change la sémantique du résultat de la fonction. Même sur une fonction qui ne renvoie qu'une seule valeur, c'est problématique et ça doit être fait le moins souvent possible. Je ne vois pas vraiment ce que le fait de renvoyer deux ou trois valeurs change au problème. Ta fonction avait un sens, elle en a un nouveau, il faut modifier le code là où elle est utilisée pour refléter le changement. Est-ce vraiment plus dur parce qu'elle renvoit deux valeurs ?
Effectivement, si la seule chose qui change c'est l'ordre dans lequel les valeurs sont renvoyées, le fait de nommer les valeurs (soit en en faisant des attributs d'un objet, soit en les mettant dans une hashtable) résout le problème. Mais concrêtement, est-ce le problème auquel on est confronté dans la vie réelle ? Un codeur ne s'amuse pas à changer l'ordre des valeurs de retour arbitrairement ; quand il change les valeurs de retour, c'est qu'il en change la signification.
Personnellement, étant adepte du Ruby, dans lequel on peut renvoyer plusieurs valeurs, je ne fais ça que pour les cas où c'est adapté. Dès que j'ai besoin d'un objet, je fais un objet. Mais si je fais une fonction qui calcule une équation de droite (ax+b), je renvoie a et b comme valeur de retour, je ne crée pas une classe EquationDeDroite. Et comme je rédige bien sagement mes tests unitaires, ça se passe bien. Mais il faut dire que je travaille surtout tout seul :)
[^] # Re: javascript
Posté par Yusei (Mastodon) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 3.
Il y a deux problèmes, le typage et le contenu des valeurs retournées. Pour le typage, rien n'empêche de typer chaque résultat d'une fonction qui en renvoie plusieurs, et dans ce cas je préfère la syntaxe simple que j'ai présentée au dessus.
Pour le contenu des valeurs, il faut bien voir qu'on change la sémantique du résultat de la fonction. Même sur une fonction qui ne renvoie qu'une seule valeur, c'est problématique et ça doit être fait le moins souvent possible. Je ne vois pas vraiment ce que le fait de renvoyer deux ou trois valeurs change au problème. Ta fonction avait un sens, elle en a un nouveau, il faut modifier le code là où elle est utilisée pour refléter le changement. Est-ce vraiment plus dur parce qu'elle renvoit deux valeurs ?
Effectivement, si la seule chose qui change c'est l'ordre dans lequel les valeurs sont renvoyées, le fait de nommer les valeurs (soit en en faisant des attributs d'un objet, soit en les mettant dans une hashtable) résout le problème. Mais concrêtement, est-ce le problème auquel on est confronté dans la vie réelle ? Un codeur ne s'amuse pas à changer l'ordre des valeurs de retour arbitrairement ; quand il change les valeurs de retour, c'est qu'il en change la signification.
Personnellement, étant adepte du Ruby, dans lequel on peut renvoyer plusieurs valeurs, je ne fais ça que pour les cas où c'est adapté. Dès que j'ai besoin d'un objet, je fais un objet. Mais si je fais une fonction qui calcule une équation de droite (ax+b), je renvoie a et b comme valeur de retour, je ne crée pas une classe EquationDeDroite. Et comme je rédige bien sagement mes tests unitaires, ça se passe bien. Mais il faut dire que je travaille surtout tout seul :)