Oui, PHP est un assemblage douteux et un langage incohérent, et ça ne risque pas de changer, c'est le piège de la compatibilité ascendante. S'ils n'avaient pas fait ce choix, cela aurait obligé les bibliothèques PHP à maintenir deux versions de leur code en parallèle, et l'adoption du typage strict n'aurait probablement eu aucun succès dans la communauté PHP. L'exemple de Python3, pas encore majoritaire dix ans après sa conception, leur a fait peur.
Un cas pratique pour être clair. J'ai un code qui utilise SwiftMailer pour les envois de mails. Si cette bibliothèque passait au typage strict et que je mettais à jour les dépendances de mon code, ça ne casserait rien dans la configuration actuelle. Sans ce typage strict à la demande, je risquerais d'avoir des erreurs à l'exécution un peu partout, avec beaucoup de travail pour migrer. Quand on lit des INT via du SQL, on récupère du texte, et il faudrait faire des typecast systématiques.
[^] # Re: Typage strict
Posté par rogo . En réponse à la dépêche Sortie de PHP 7.0 - un nouveau départ. Évalué à 8.
Oui, PHP est un assemblage douteux et un langage incohérent, et ça ne risque pas de changer, c'est le piège de la compatibilité ascendante. S'ils n'avaient pas fait ce choix, cela aurait obligé les bibliothèques PHP à maintenir deux versions de leur code en parallèle, et l'adoption du typage strict n'aurait probablement eu aucun succès dans la communauté PHP. L'exemple de Python3, pas encore majoritaire dix ans après sa conception, leur a fait peur.
Un cas pratique pour être clair. J'ai un code qui utilise SwiftMailer pour les envois de mails. Si cette bibliothèque passait au typage strict et que je mettais à jour les dépendances de mon code, ça ne casserait rien dans la configuration actuelle. Sans ce typage strict à la demande, je risquerais d'avoir des erreurs à l'exécution un peu partout, avec beaucoup de travail pour migrer. Quand on lit des INT via du SQL, on récupère du texte, et il faudrait faire des typecast systématiques.