[Résolu] Retours multiples de fonction : tableau, tableau associatif, ou objet ?

[srm]

Non mais je pousse le débat surtout.
Car à la base moi aussi je fais des fonctions parfois qui retourne plusieurs valeurs.
Mais à la réflexion faite j'ai l'impression que c'est une erreur de conception et que l'on devrait toujours s'en passer.

Ou alors quand c'est vraiment des données communes indissociables faisant partie d'un même "objet".
Par exemple getCoords(); qui va retourner un tableau array(x, y).
Dans ce cas là oui clairement on retourne plusieurs valeurs.
Mais ici les exemples donnés ne rentrent pas dans ce cas et donc devraient selon moi ne retourner qu'une valeur.

[niahoo]

Bien, mais pour quelle raison ? Si c'est plus pratique de retourner plusieurs valeurs, pourquoi s'en passer ?

Comme je le disais, je préfère réserver des exceptions pour des erreurs de déroulement de l'application : fichier ou base de données inaccessibles/inexistantes alors que leur présence est requise, permission de fichier insuffisante (dans le cadre d'un jeu web, si tu codes un OS ce n'est pas une exception).

Par exemple, dans eve quand tu te fais péter ton ship tu spammes comme un demeuré le bouton de warp. dans wow, quand ta super technique qui va te sauver la peau a encore 3 secondes de CD tu la spamme comme un boeuf. Bon ben ça c'est un déroulement normal.

en tapant sur ta techinque, ça déclenche un bout de code qui peut retourner plusieurs valeurs:
(lancée) ; (cooldown, 3 secondes) ; (silenced) ; (no target) ; (bad target, friend) ; (trop loin, 25 mètres)

Le paradigme objet voudrait qu'on renvoie des instances de retour d'action, et que la classe retour d'action de type cooldown propose un méthode pour connaitre le temps restant.
Si tu veux faire de l'objet pur et dur alors vos propositions d'un objet de retour est la plus logique.

Sans pattern matching en PHP c'est pas facile de faire autrement que sonder un tableau si on ne souhaite pas utiliser un objet. Mais ce n'est pas un problème.
Si tu as un constructeur qui t'assure que le membre temps restant de ton objet cooldown soit bien enregistré, afin que ta méthode get_cd renvoie bien une donnée juste, il n'y a pas de raison que quand tu vas mettre ce temps dans la case 2 de ton tableau elle n'y soit plus quand tu le récupère de l'autre côté de ta fonction.

L'objet n'apporte pas ici de robustesse supplémentaire. Mais bien sur il ne faut pas faire n'importe quoi avec son tableau ensuite. On respectera la structure comme elle a été définie. Si cette structure devient au fil des améliorations un truc à 50 cases avec des sous-sous-objets, bon ben là oui on se fait un système d'héritage de classes, c'est clair. (Enfin, en php ou autre langage objet)

[srm]

Pourquoi ?
Bah parce que je pense (je me trompe peut-être mais j'en doute) que ça correspond à une bonne logique de programmation et de découpage.
Comme par moment passer par un pattern adaptateur, ou un pattern proxy.

Concernant tout ceci je cherche de la doc, mais mon petit doigt me dit que j'ai raison

Edit :
Avant de trouver de la doc, je rajoute quand même quelque trucs concernant ton exemple et comment je vois les choses :
(lancée) = return true;
(cooldown, 3 secondes) = throw new ExceptionCoolDown(3);
(silenced) = throw new ExceptionSilenced();
(no target) = throw new ExceptionNoTarget();
(bad target, friend) = throw new ExceptionTargetFriend();
(trop loin, 25 mètres) = throw new ExceptionFarAway(25);

Mais si on veut faire encore plus propre, on fait plutôt :
(lancée) = return true;
(cooldown, 3 secondes) = throw new CastingException('cooldown', 3);
(silenced) = throw new CastingException('silenced');
(no target) = throw new CastingException('notarget');
(bad target, friend) = throw new CastingException('wrongtarget', 'friend');
(trop loin, 25 mètres) = throw new CastingException('toofar', 25);

Et si je réfléchis à un code découpé ainsi, qui soit me return true, soit me lance des exceptions pour me dire pourquoi il n'a pas pu faire l'action demandé.
Pour moi il y a aucun doute possible, c'est largement plus propre.

[niahoo]

Que veux tu que je te dise ? C'est ton point de vue. Perso mes vraies exceptions seraient perdues, et le nombres de lignes 'catch' sera chiant à écrire.

[srm]

C'est comme si quelqu'un t'expliquait la POO et que tu disais que c'était son point de vue et que tu continuerais en procédurale
Et bien sûr sans oublier "le nombre de class à écrire serait chiant"

Faisons un truc, écrit nous un code simple, d'une centaine de ligne à tout casser avec ce type de cas et ou tu utilises une ou plusieurs fonctions qui retourne plusieurs données.

Et je te fais l'équivalent en exception ok ?

[niahoo]

non, si je choisis de faire du procédural, alors c'est une décision arbitraire.
Ici je dis que c'est une histoire de goûts, certes, mais je justifie quand même mon choix par le souhait de différencier une erreur dans l'application d'un panel de codes de retour d'une fonction.

Propose moi un problème à résoudre qui soit intéressant, je ne vais pas écrire 100 lignes de codes dans le vent.

[srm]

Il ne s'agit pas d'une erreur mais d'une exception.
Ça n'est pas pour rien que l'on parle de lever une exception.

[srm]

En tout cas en cherchant de la documentation et demandant de l'aide un peu partout, on m'a donné sur le salon #ruby une doc qui semble très intéressante : http://www.subtextual.org/OOPSLA07.pdf
Je ne l'ai pas encore potassé par contre
Attention ça semble très technique

---

Visiblement il faut mieux utiliser les exceptions uniquement dans les cas d'exception.
Se contenter de retourner un tableau dans les cas simple et très bien.

Par contre si on commence à entrer dans un cas plus complet et complexe il vaut mieux comment à utiliser une couche structurée.

[niahoo]

Je suis d'accord, si le tabeau commence a avoir plien de cases et qu'il est nécéssaire de créer des focntions qui exploitent ce tableau pour formaliser tout ça alors en faire une classe si OOPL