Je connais pas trop les langage non objets, donc je m'abstiendrais d'en parler.
Dans un langage objet par contre, par essence, tu vas passer par des classes pour ce genre d'operations (ie, tu ne vas pas utiliser une "fonction" mais une methode d'une classe).
Deja en java, utiliser un tableau, c'est pas courant. Tu vas utiliser une List ou un Set suivant le besoin. List et Set qui sont des classes et peuvent donc avoir des methodes, a tout hasard getMin et getMax.
Tu peux creer une classe ManipulateurDeList qui prend une list ou tableau en input ou quoi que ce soit d'autre.
La philosophie voudrait meme que tu utilises l'interface Comparable pour pouvoir appliquer getMin et getMax a autre chose que des valeurs numeriques. Ca prend une autre dimension, c'est plus complique, mais ca tombe bien, c'est utilise pour faire des choses complique, pas pour faire des choses simple vite fait.
Si tu as *besoin* de retourner 2 objets, c'est que ta structure d'objet et/ou ton api sont mauvaises.
Disons que tu vas pas creer une classe rien que pour ca en codant ta methode, tu vas te poser et reflechir avant meme de faire la classe en question et reflechir a son API. Si ca arrive, tu es totalement passe a cote des fondements des langages pur objets.
Oui, c'est chiant, et c'est pour ca que l'objet pur est lourd a utiliser, faut avoir une bonne raison de faire de l'objet pur.
Je veux bien croire qu'il ya qq cas specifique limites, mais ca ne justifie pas de faire rentrer une immondice pareille dans le langage.
Je sais pas si tu maitrises bien les langages objets ou pas (aucune animosite ni condescendance), mais j'ai comme l'impression que tu abordes les langages objet avec une philosphie imperatif: forcement ca va pas passer (je te rassure, je ferais tres certainement pareil dans l'autre sens).
Le probleme que je vois avec les retours multiples, c'est que si tu retournes un n-uplet (int, int, int), tu n'as pas la moindre idee de ce qu'est chaque parametre.
C'est une grouikerie parce que ca te permet de coder au kilometre sans meme penser aux implications de ton code ,comment il va etre utilise ou comment il va etre maintenu.
Avec un objet, tu vas faire un getMin() et t'es sur de pas te planter.
Avec une structure tu vas faire un retour.min, et pareil, sur de pas te planter.
Avec un n uplet tu fais un retour.get(0) sans plus d'infos, c'est du code qui ne demande qu'a te peter a la gueule. Jean Rene va passer par la, modifier le code, ca va te retourner (max, min) au lieu de (min, max) parce qu'il a patche a 4h00 du matin, et tu va mettre 2 jours a trouver le bug.
Pendant ec temps la, moi je bosse^W troll sur LFR.
A la rigueur, faire des trucs comme en actionscript/javascript: retourner un objet dynamique (ie avec des membres cree a la volee), ca parait un compromis raisonnable. Mais conceptuellemet, c'est pareil, t'as juste une souplesse a l'utilisation de creer ta classe dynamiquement.
Sinon, pour les liste de parametres, j'ai du mal a voir l'interet, peut etre que je suis trop idiot ou ferme. Toujours est il que je trouve ca tres crade aussi.
[^] # Re: javascript
Posté par thedude . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 3.
Dans un langage objet par contre, par essence, tu vas passer par des classes pour ce genre d'operations (ie, tu ne vas pas utiliser une "fonction" mais une methode d'une classe).
Deja en java, utiliser un tableau, c'est pas courant. Tu vas utiliser une List ou un Set suivant le besoin. List et Set qui sont des classes et peuvent donc avoir des methodes, a tout hasard getMin et getMax.
Tu peux creer une classe ManipulateurDeList qui prend une list ou tableau en input ou quoi que ce soit d'autre.
La philosophie voudrait meme que tu utilises l'interface Comparable pour pouvoir appliquer getMin et getMax a autre chose que des valeurs numeriques. Ca prend une autre dimension, c'est plus complique, mais ca tombe bien, c'est utilise pour faire des choses complique, pas pour faire des choses simple vite fait.
Si tu as *besoin* de retourner 2 objets, c'est que ta structure d'objet et/ou ton api sont mauvaises.
Disons que tu vas pas creer une classe rien que pour ca en codant ta methode, tu vas te poser et reflechir avant meme de faire la classe en question et reflechir a son API. Si ca arrive, tu es totalement passe a cote des fondements des langages pur objets.
Oui, c'est chiant, et c'est pour ca que l'objet pur est lourd a utiliser, faut avoir une bonne raison de faire de l'objet pur.
Je veux bien croire qu'il ya qq cas specifique limites, mais ca ne justifie pas de faire rentrer une immondice pareille dans le langage.
Je sais pas si tu maitrises bien les langages objets ou pas (aucune animosite ni condescendance), mais j'ai comme l'impression que tu abordes les langages objet avec une philosphie imperatif: forcement ca va pas passer (je te rassure, je ferais tres certainement pareil dans l'autre sens).
Le probleme que je vois avec les retours multiples, c'est que si tu retournes un n-uplet (int, int, int), tu n'as pas la moindre idee de ce qu'est chaque parametre.
C'est une grouikerie parce que ca te permet de coder au kilometre sans meme penser aux implications de ton code ,comment il va etre utilise ou comment il va etre maintenu.
Avec un objet, tu vas faire un getMin() et t'es sur de pas te planter.
Avec une structure tu vas faire un retour.min, et pareil, sur de pas te planter.
Avec un n uplet tu fais un retour.get(0) sans plus d'infos, c'est du code qui ne demande qu'a te peter a la gueule. Jean Rene va passer par la, modifier le code, ca va te retourner (max, min) au lieu de (min, max) parce qu'il a patche a 4h00 du matin, et tu va mettre 2 jours a trouver le bug.
Pendant ec temps la, moi je bosse^W troll sur LFR.
A la rigueur, faire des trucs comme en actionscript/javascript: retourner un objet dynamique (ie avec des membres cree a la volee), ca parait un compromis raisonnable. Mais conceptuellemet, c'est pareil, t'as juste une souplesse a l'utilisation de creer ta classe dynamiquement.
Sinon, pour les liste de parametres, j'ai du mal a voir l'interet, peut etre que je suis trop idiot ou ferme. Toujours est il que je trouve ca tres crade aussi.