(Quand) devrais-je utiliser type hinting en PHP?

Question

Je ne comprends pas la motivation des auteurs PHP pour ajouter le type d'indication. Je vivais heureux avant qu'il apparaisse. Puis, comme il a été ajouté à PHP 5, j'ai commencé à spécifier des types partout. Maintenant, je pense que c'est une mauvaise idée, dans la mesure où le typage de canard assure un couplage minimal entre les classes, et tire parti de la modularisation et de la réutilisation du code.

On a l'impression que les astuces de type divisent la langue en 2 dialectes: certaines personnes écrivent le code en style statique, avec les indices, et d'autres s'en tiennent au bon vieux modèle de langage dynamique. Ou n'est-ce pas la situation "tout ou rien"? Dois-je mélanger ces deux styles, le cas échéant?

Answer 1

Il ne s'agit pas de typage statique vs dynamique, php est encore dynamique. Il s'agit de contrats pour les interfaces. Si vous savez qu'une fonction nécessite un tableau comme l'un de ses paramètres, forcez-le dans la définition de la fonction. Je préfère échouer rapidement, plutôt qu'errer plus tard dans la fonction.

(Notez également que vous ne pouvez pas spécifier le type laissant entendre pour bool, int, string, flotteur, ce qui est logique dans un contexte dynamique.)

Answer 2

Vous devez utiliser l'indication de type lorsque le code de votre fonction dépend définitivement du type du paramètre transmis. Le code génèrerait une erreur de toute façon, mais l'indice de type vous donnera un meilleur message d'erreur.

Answer 3

Sans le type laissant entendre qu'il serait impossible pour l'IDE de connaître le type de un paramètre de méthode et donc fournir l'intellisense approprié - votre éditeur a intellisense, n'est-ce pas? ;). Il faut dire que je suppose que les IDE l'utilisent pour intellisense, car c'est la première fois que j'entends parler de type hinting en PHP (merci pour l'astuce btw).

Answer 4

Si jamais vous décidez de faire des indices de type, faites-le au moins en utilisant des interfaces au lieu de classes concrètes ou abstraites. La raison est simple, PHP n'autorise pas l'héritage multiple mais permet d'implémenter plusieurs interfaces. Donc, si quelqu'un essaye d'utiliser votre bibliothèque, il n'aura pas de difficultés à implémenter votre interface, par opposition au cas où il devrait étendre votre classe abstraite/concrète étant donné qu'il en étend déjà une autre déjà.

Answer 5

La motivation du groupe PHP pour ajouter une indication de type était de fournir aux personnes habituées à la POO Java une autre fonctionnalité qui rendrait la plate-forme plus familière, confortable et attrayante. Ceci, à son tour, rendrait PHP plus «prêt pour l'entreprise», ce qui aiderait Zend à développer son activité principale.

Marketing mis à part, il a ses utilisations. Si vous écrivez une méthode qui agit sur un paramètre d'une manière spécifique qui provoquerait des échecs involontaires (souvent silencieux) si le paramètre était autre chose, l'utilisation de l'indication de type assure que le code se rompra au cours du développement plutôt que de rompre en production.

Answer 6

La recherche de type est un point de débat dans notre société (surtout les gens de Java aiment ça), et je suis un très vieux programmeur PHP (et un programme dans d'autres langues).

Mon conseil est d'éviter les indices de type et d'inclure des gestionnaires try/catch dans chaque fonction complexe. La recherche de type oblige une application à s'appuyer sur l'environnement de gestion des exceptions des appelants, qui est généralement mauvais et n'est pas testé, ce qui constitue le principal problème. Pour les applications web, cela se traduit par l'écran blanc de la mort, pour le lot il en résulte simplement une sortie fatale sans journalisation des bons messages dans la plupart des cas, et vous êtes assis à vous gratter la tête en essayant de recréer le problème retour à résoudre.La gestion des exceptions locales fournit un scénario de test plus contrôlé, y compris les types de données et les valeurs de données, ce qui donne une suite de tests beaucoup plus complète comparée à un chemin de gestion des exceptions difficiles à tester dans l'appelant en transmettant une erreur tapez et attendez l'exception. Le test d'exception échoue également dans de nombreux cas en raison de problèmes de version de la pile (certaines versions de PHP comme 5.4 ne détectent pas correctement les erreurs "fatales" et ergo phpunit meurt simplement en cassant les suites de tests. Problème spécifique, mais dans mon expérience, il n'est pas nécessaire d'utiliser hinting, les gens habitués à un langage typé acceptent PHP mieux sans se rendre compte de l'impact, et provoquent des scénarios de test beaucoup plus complexes. Le Java et les autres utilisateurs de langage typé n'acceptent pas ou ne comprennent pas comment exploiter et profiter des paramètres de type mixte par défaut en PHP ... Ils apprendront un jour, mais seulement s'ils embrasser la voie PHP. ;-)

Les meilleures leçons sont apprises lors du développement de scénarios de tests basés sur des unités PHP robustes, et qui éclaireront normalement pourquoi les indices de type sont une douleur dans la crosse liée au test, et causent beaucoup plus de problèmes que de bien ... Pour chacun d'entre eux, et mes applications fonctionnent mieux et plus fiable et les tests s'avèrent beaucoup plus complets avec une couverture de code généralement de 100%, y compris les chemins d'accès dans les fonctions locales.