Non, ça ne me semblait pas bon, puisque dans les langages où le retour est typé, c'est pareil (changer le typage de retour cassera les autres codes) et ...
Sur du PHP, quelqu'un qui se basait sur le typage du retour ferait une erreur (puisque les retours ne sont pas typés par le langage, pour le moment).
PHP n'a en fait pas le problème que tu essaies de faire apparaitre (à savoir, que la classe appelée est forcée de retourner un type d'objet précis, les types de base était interchangeables en PHP).
Et si l'appelé s'adapte à l'interlocuteur, comment cela se passe sur une lib (un .phar, qu'on n'a pas le droit de modifier donc)?
Pour moi, le mot-clef return est juste franchement bien fichu puisqu'il se charge de tout ce bazar (passer le conteneur de résultat en paramètre à l'appelé, que l'appelé passe son résultat à ce conteneur, que ce conteneur transmette le résultat à l'appeleur, et que l'appeleur reprenne le fil de ses opérations) que tu émules dans le code au lieu de le faire dans le langage. Dans un appel de méthode/fonction, l'appeleur est toujours passé implicitement à l'appelé (d'où l'existence d'une stack trace). Lis-le comme push $result au lieu de return $result si tu veux.
Citation :...dans le cas de PHP, j'ai deux objections:
• La prochaine version implémentera (d'après niahoo) le typage des retours, donc la compilation sera cassée
• Le langage PHP actuel part du principe que les retours sont non typés, donc si un code considère qu'un retour est toujours d'un typage donné, en PHP, c'est une erreur puisque le langage autorise n'importe quel retour. Du coup, les codes "mal faits" (qui "typent" les retours alors que le langage ne le fait pas) seront effectivement cassés. Les bons codes (qui vérifient les retours car ceux-ci sont non-typés) ne seront pas cassés: PotDeVin tombera dans les if (!is_a($retour, Papiers)) throw new \Exception(...);.
Sur du PHP, quelqu'un qui se basait sur le typage du retour ferait une erreur (puisque les retours ne sont pas typés par le langage, pour le moment).
PHP n'a en fait pas le problème que tu essaies de faire apparaitre (à savoir, que la classe appelée est forcée de retourner un type d'objet précis, les types de base était interchangeables en PHP).
Et si l'appelé s'adapte à l'interlocuteur, comment cela se passe sur une lib (un .phar, qu'on n'a pas le droit de modifier donc)?
Pour moi, le mot-clef return est juste franchement bien fichu puisqu'il se charge de tout ce bazar (passer le conteneur de résultat en paramètre à l'appelé, que l'appelé passe son résultat à ce conteneur, que ce conteneur transmette le résultat à l'appeleur, et que l'appeleur reprenne le fil de ses opérations) que tu émules dans le code au lieu de le faire dans le langage. Dans un appel de méthode/fonction, l'appeleur est toujours passé implicitement à l'appelé (d'où l'existence d'une stack trace). Lis-le comme push $result au lieu de return $result si tu veux.