Pourquoi PHP 7.1 est (déjà) une mauvaise version

La version 7.1 de PHP est sortie en Bêta. C’est l’occasion de faire le tour de ses nouvelles fonctionnalités et – aussi – de voir ce qui en fait une mauvaise version en terme de gouvernance de projet.

Les nouvelles fonctionnalités de PHP 7.1

Tout d’abord au rang des nouvelles fonctionnalités à paraître dans PHP 7.1, on retrouve un complément au typage de retour, introduit dans PHP 7.0. Cette fonctionnalité souffrait en effet d’un manque, celui de pouvoir déclarer que le retour pouvait également être null. Comme le précise PHP 7.1 : RFC sur les types de retours null, c’est relativement courant de vouloir retourner null lorsqu’un problème ne permet pas d’avoir une valeur à retourner. PHP 7.1 corrige donc le tir en ajoutant ce support. Concernant les types de retour, on a également le type de retour « void » qui a été ajouté. Oublié lors de la release de PHP 7.0, il permet de spécifier qu’une fonction ne doit rien retourner.

On trouve ensuite l’ajout d’une nouvelle syntaxe pour la structure « list », qui permet de simplifier l’utilisation de cette fonction avec une syntaxe plus proche de celle de l’assignation de tableau. On peut également désormais spécifier les clés à récupérer lorsqu’on utilise list, toujours pratique. Autour des tableaux on trouvera également l’ajout du pseudo type « iterable » qui permet désormais de spécifier que l’on attends un tableau ou un objet qui implémente Traversable.

On a également l’ajout d’une méthode « fromCallable » sur l’objet native « Closure », permettant de transformer une callable en Closure afin de le manipuler plus facilement.

Deux dernières nouveautés ont particulièrement retenu mon attention: la possibilité d’affecter des visibilités aux constantes de classes: permettant d’avoir des constantes publiques (par défaut), privées ou protégées ainsi que la possibilité de catcher plusieurs types d’exception dans une seule instruction catch. Cela permet une meilleure factorisation du code et donc une meilleure lisibilité !

Vous pouvez retrouver toute la liste des RFC implémentées pour PHP 7.1, afin d’y voir pêle-mele le support d’offset négatifs généralisé, la meilleure gestion de précision des nombres flottants en json, le support du PUSH HTTP/2 dans curl, etc.

Cependant, PHP 7.1 est une version mineure et, malgré cela, elle propose plusieurs BC break allant à l’encontre des stratégies de versionning sémantique communément admis aujourd’hui.

Les BC Breaks introduits dans PHP 7.1

2 3 BC breaks ont été introduits dans PHP 7.1, malgré les messages postés par Pascal Martin au nom de l’AFUP.

Too few arguments exception

La première cassure de compatibilité ascendante concerne la gestion des fonctions appelées sans suffisamment d’arguments. Jusqu’en PHP 7.0 ce cas causait l’apparition d’une simple notice. Désormais il s’agirat d’une exception de type « Error » qui sera lancée lorsqu’il manque un argument. On passe donc d’une notice à une erreur fatale. En effet, en l’absence de gestionnaire d’exception qui prend en charge correctement les exceptions de type Error (qui, pour rappel, n’héritent pas de la classe Exception) les exceptions seront converties en erreur fatales.

On notera donc le message posté par Pascal Martin sur la mailing list internals qui prend clairement position pour refuser cette RFC en PHP 7.1.

Fonctionnement incohérent de $this

Cette cassure de rétro compatibilité risque d’impacter des codes legacy qui ont pu tirer parti de ce fonctionnement incohérent. Il était en effet possible de déclarer, dans un contexte objet ou non, une variable nommée $this. Cela ne sera désormais plus possible puisque toute assignation d’une valeur à une variable nommée $this (directement ou indirectement) lancera désormais une exception de type Error dès la compilation. Cela a été voté dans la RFC « Fix inconsistent behaviour of $this variable ». Si la RFC concernant la gestion des arguments aura eu un résultat mitigé (avec 39 voix pour, 11 voix contres) celle-ci n’a semble-t-il connu aucune voix discordante avec 43 voix pour et aucune (!) voix contre. On retrouve encore une fois un message de Pascal Martin qui prend position pour décaler cette RFC en PHP 8.0 et, dans l’intermédiaire, lancer une erreur de dépréciation.

Warning concernant les chaines invalides en arithmétique

Merci à « un lecteur » qui m’a signalé un autre BC Break que j’avais oublié: Warn about invalid strings in arithmetic. Ce changement qui a pour but de lever une warning lorsqu’on cherche à exploiter sans cast, une chaîne comme un entier mais que la chaîne ne constitue pas un entier valide. Ce changement qui introduit une BC break a eu des répercussions jusque dans des projets comme symfony. Il va donc falloir faire très attention au combo PHP / Symfony pour ne pas avoir de surprise lors de la montée de version.

Is it worth it ?

Dans certains cas on peut justifier les BC breaks sur des versions mineures, principalement pour des raisons de sécurité. Dans ces cas c’est juste incompréhensible, les questions de cohérence et de nettoyage ne doivent pas en effet prendre le pas sur la maintenabilité d’une application. On peut entendre régulièrement des statistiques qui démontrent que l’adoption des versions récentes (>= PHP 5.5) de PHP sont très compliquées. Nous pensions avoir enfin la possibilité avec PHP 7 et les très belles nouveautés qui y sont présentes, de pouvoir effectuer des montés de version sans se soucier du code existant. La communauté derrière PHP vient de nous montrer tout le contraire et nous promet encore de nombreuses heures à chercher des bugs incongrus apparus entre 2 versions de PHP, pour des questions d’esthétisme du code, cela n’a aucun sens. PHP est et restera avec PHP 7.1 un très bon langage, seulement il faut absolument interdire les BC breaks pour d’autres raisons que la sécurité sur des versions mineures.

Vous aimerez aussi...

5 réponses

  1. Jérémy dit :

    Je ne comprends pas la partie sur les Error qui ne sont pas correctement catchées.

    Pourquoi un catch(Error) ou catch(Throwable) ne pourrait pas gérer ce genre de cas?

    En autre BC break tu as aussi le tempnam qui lance une notice quand il fallback sur le sys temp dir.

  2. Xavier dit :

    Effectivement si tu catche Error tu gèreras ce cas là sans problème.
    Simplement ici on est dans le cadre d’une nouveauté de PHP7, je pense donc à du code conçu en PHP 5, qui ne catchait donc pas les Error / Throwable, on va avoir une erreur fatale. Je te l’accorde ce n’est pas exposé très clairement !

  3. Pierre dit :

    Même si les BC sont un peu discutable, il faut toujours faire très attentions aux versions mineur.
    Par exemple le nouveau reserved keyword Void à déranger bon nombre de lib php, pourtant on considère pas ça comme un BC mais le résultat est le même. Je trouve que ça force à bouger plus vite, et ça fait pas de mal à PHP.
    Titré « déjà une mauvaise version » c’est très négatif pour quelques choses qui ne l’ait pas tant que ça.

  4. Joey dit :

    Apparemment, l’auteur de cet article et Pascal Martin sont très, très, très conservateurs.
    Personnellement je trouve cette version très bien, et je n’ai eu qu’un truc à changer dans mes centaines de milliers de lignes de codes : un $i – i qui provoquait un warning alors qu’il passait avant. Et c’était un bug, c’était censé être $i – 1.

    Quant aux autres changements, ils ne peuvent impacter que du code extrêmement cradingue qui a sérieusement intérêt à être revu. C’est très bien de faire ce genre de choses sur une release intermédiaire plutôt que de réserver plus de changements pour les versions majeures.

    De plus, rien n’oblige à passer à 7.1. Un apt-get upgrade ne fera pas passer de 7.0 à 7.1, alors pourquoi descendre cette version ? Mystère.

  5. BarryFed dit :

    Online Casino Rewards On Net – BlackJack Ballroom Casino, Casino On Net.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *