{"id":1039,"date":"2015-10-09T11:59:24","date_gmt":"2015-10-09T09:59:24","guid":{"rendered":"http:\/\/www.lafabriquedecode.com\/blog\/?p=1039"},"modified":"2015-10-12T13:53:40","modified_gmt":"2015-10-12T11:53:40","slug":"php-7-les-types-de-retour","status":"publish","type":"post","link":"http:\/\/www.lafabriquedecode.com\/blog\/2015\/10\/php-7-les-types-de-retour\/","title":{"rendered":"PHP 7 : les types de retour"},"content":{"rendered":"

Un futur vers les retours<\/h1>\n

On continue dans la s\u00e9rie \u00ab\u00a0Ces nouveaut\u00e9s qui rendent heureux\u00a0\u00bb avec l’annonce de la possibilit\u00e9 de forcer des types de retour<\/strong> de fonctions dans PHP 7<\/strong> ! Cette avanc\u00e9e majeure a fait l\u00e0 encore l’objet de d\u00e9bats assez vifs au sein de la communaut\u00e9 des d\u00e9veloppeurs PHP, avec des RFC critiqu\u00e9es, d’autres \u00e9cart\u00e9es et d’autres qui reviendront un jour ou l’autre d’outre-tombe !<\/p>\n

\"Terminator,<\/a>

Le type de retour le plus connu au monde !<\/p><\/div>\n

C’est l’histoire d’un type…<\/h1>\n

Scalaire ou pas, nous pouvons maintenant signifier un type de retour dans les d\u00e9clarations de nos fonctions, sous la forme suivante :<\/p>\n

\r\n<MODE D'ACCES> function <NOM> (liste de param\u00e8tres) : <TYPE DE RETOUR>\r\n<\/pre>\n
La position de ce type de retour a fait d\u00e9bat d’entr\u00e9e de jeu, certains d\u00e9veloppeurs ne souhaitant pas le voir devant<\/em> le nom de la fonction, comme c’est le cas en C ou Java, pour des raisons de commodit\u00e9 lors des recherches dans le code (chercher \u00ab\u00a0function mafonc\u00a0\u00bb n’aurait plus fonctionn\u00e9 si elle avait du s’appeler \u00ab\u00a0function int mafonc\u00a0\u00bb).<\/p>\n
Commen\u00e7ons avec des types non scalaires :<\/p>\n
\r\nfunction eleves(): array {\r\n    return ["jean", "eric", null];\r\n}\r\n\r\nvar_dump(eleves());\r\n\r\n\/*\r\narray(3) {\r\n  [0]=>\r\n  string(4) "jean"\r\n  [1]=>\r\n  string(4) "eric"\r\n  [2]=>\r\n  NULL\r\n}\r\n*\/\r\n<\/pre>\n
ou bien encore :<\/p>\n
\r\nclass Eleve {\r\n    private $_nom;\r\n    private $_prenom;\r\n\r\n    public function __construct ($nom, $prenom) {\r\n        $this->_nom = $nom;\r\n        $this->_prenom = $prenom;\r\n    }\r\n}\r\n\r\nfunction eleve($n, $p): Eleve {\r\n    return new Eleve ($n, $p);\r\n}\r\n\r\nvar_dump(eleve("Rack", "Eric"));\r\n\r\n\/*\r\nobject(Eleve)#1 (2) {\r\n  ["_nom":"Eleve":private]=>\r\n  string(4) "Rack"\r\n  ["_prenom":"Eleve":private]=>\r\n  string(4) "Eric"\r\n}\r\n*\/\r\n<\/pre>\n
Nous avons utilis\u00e9 dans l’exemple pr\u00e9c\u00e9dent des types non scalaires, respectivement tableau (array<\/em>) et objet (de la classe Eleve<\/em>).<\/p>\n
Nous pouvons aussi renvoyer des types scalaires, tels que int<\/strong>, float<\/strong>, bool<\/strong> ou encore string<\/strong> :<\/p>\n
\r\nfunction qi(): int {\r\n    return 150;\r\n}\r\n\r\nvar_dump(qi());\r\n<\/pre>\n
Si je modifie le type de retour pour essayer les quatre types susnomm\u00e9s, voici ce que j’obtiens :<\/p>\n
int(150)\r\nbool(true)\r\nstring(3) \"150\" \r\nfloat(150)\r\n<\/pre>\n
Pensez \u00e0 activer le typage strict<\/strong> en faisant figurer en premi\u00e8re ligne de votre fichier de test (ou plus proprement, dans l’autoloader de votre application) la directive<\/strong> maintenant bien connue de ceux qui veulent b\u00e9n\u00e9ficier des plus r\u00e9centes fonctionnalit\u00e9s en mati\u00e8re de typage strict, \u00e0 savoir:<\/p>\n
\r\ndeclare(strict_types=1);\r\n<\/pre>\n
Comme toujours, il faut respecter le contrat, sinon gare ! Vous ne pouvez pas \u00e9crire :<\/p>\n
\r\nfunction quotientintellectuel(): int {\r\n    return null;\r\n}\r\n<\/pre>\n
ou bien encore:<\/p>\n
\r\nfunction quotientintellectuel(): int {\r\n    return "150";\r\n}\r\n<\/pre>\n
Sous peine de courroucer PHP, qui, pour le premier exemple, vous jettera \u00e0 la figure un joli :<\/p>\n
Fatal error: Uncaught TypeError: Return value of quotientintellectuel()\r\n must be of the type integer, null returned \r\n<\/pre>\n
Invariance<\/h1>\n
Elle reste toujours de mise, \u00e0 savoir que les signatures des m\u00e9thodes h\u00e9rit\u00e9es ou impl\u00e9ment\u00e9es doivent rester EXACTEMENT les m\u00eames dans les sous-types. Ainsi, si vous \u00e9crivez ceci, vous vous provoquerez naturellement l’ire du compilateur :<\/p>\n
\r\nclass Eleve {}\r\n \r\ninterface EleveDao {\r\n    function trouverParNom($nom): Eleve; \r\n}\r\n \r\nclass EleveSqlDao implements EleveDao {\r\n\r\n    function trouverParNom($nom) {\r\n        \/\/ mes plus belles requ\u00eates SQL \r\n        return new Eleve();\r\n    }\r\n}\r\n<\/pre>\n
\r\nFatal error: Declaration of EleveSqlDao::trouverParNom($nom) must be compatible with EleveDao::trouverParNom($nom): Eleve\r\n<\/pre>\n
Notez que ce comportement pourrait \u00eatre modifi\u00e9 dans les versions futures du langage.<\/p>\n
Peut-on renvoyer \u00ab\u00a0rien\u00a0\u00bb ?<\/h1>\n
Il y a eu une tentative<\/a> d’introduire un type void<\/strong> comme en C\/C++ ou Java mais cette proposition a \u00e9t\u00e9 rejet\u00e9e. Vous savez que par d\u00e9faut une fonction PHP renvoie null :<\/p>\n
\r\nfunction rien() {}\r\n\r\nvar_dump(rien());\r\n# NULL\r\n<\/pre>\n
Quand on \u00e9crit void<\/strong>, on notifie que la fonction ne renvoie rien. Or null par d\u00e9faut est retourn\u00e9<\/strong> par PHP, ce sont deux choses diff\u00e9rentes.<\/p>\n
Avec void on ne renvoie rien, avec return null on renvoie \u00ab\u00a0absence de valeur\u00a0\u00bb !<\/p><\/blockquote>\n
Quid des fonctions sp\u00e9ciales ?<\/h1>\n
Certaines fonctions ne sont pas autoris\u00e9es \u00e0 faire usage des types de retour :<\/p>\n