La version 8.1 de PHP et création de la fondation PHP

Posté par  . Édité par xdelatour, Florent Zara, Xavier Teyssier, windu.2b, Benoît Sibaud, palm123 et Pierre Jarillon. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
44
2
déc.
2021
PHP

En fin d’année 2021 et sur la lancée habituelle PHP passe en version 8.1. Tout comme les autres versions, elle sera maintenue activement pendant deux années et elle recevra seulement des correctifs de sécurité une année de plus.

Élephant PHP sur un ordinateur portable

Sommaire

Quoi de neuf

Les nouveautés majeures

Les types énumérés

Jusqu’à présent cette structure n’était pas présente nativement dans le langage, elle était néanmoins implémentée dans diverses bibliothèques. C’est la bonne occasion de se débarrasser des classes remplies de constantes.

<?php
enum IP
{
  case V4;
  case V6;
}

// la méthode statique cases() est automatiquement implémentée
IP::cases(); // [IP::V4, IP::V6]

$versionOf = fn(string $address): ?IP => {
 match(true){ 
  case isIpV4($address) => IP::V4,
  case isIpV6($address) => IP::V6,
  default => null
 }
};

$versionOf("192.168.0.1); // IP::V4

Propriétés de classe en lecture seule

Cette fonctionnalité, qui existe déjà dans d’autres langages (C# et TypeScript), fait son arrivée. Elle vous permettra d’avoir un objet dont les propriétés ne pourront plus être modifiées après l’instanciation. Ça va désormais être rapide pour créer des DTO.

class QuelBeauDTO
{
    public function __construct(public readonly string $message){}
}

$dto = new QuelBeauDTO("LinuxFR");

echo($dto->message); // LinuxFR

$dto->message = "Vive les moules"; //Fatal error: Uncaught Error: Cannot modify readonly property QuelBeauDTO::$message

Les types intersection purs

Après les types unions lors de la version précédente, voici l’intersection. Une bonne solution pour favoriser la composition d’interface et améliorer la modularité de nos développements.

interface A{ function a(): string;}

interface B{ function b(): string;}

class Coucou implements A, B
{
    function __construct(private readonly string $a, private readonly string $b){}

    function a(): string
    {
       return $this->a;
    }

    function b(): string
    {
       return $this->b;
    }
}

$ab = new Coucou("coucou", "toto");

$fn = fn(A&B $ab): string => "{$ab->a()} {$ab->b()}";

echo($fn($ab)); // coucou toto

La notion de pureté vient du fait que pour le moment il n’est pas possible d’avoir une signature du genre : A&B|C. Une discussion houleuse s’est tenue quelques jours avant le gel des fonctionnalités sur la possibilité d’avoir des null et la syntaxe qui l’accompagnerait. Pour rappel, les types union ont intégré le langage en version 8.0.

Autres nouveautés

Du code asynchrone avec les Fibers

Jusqu’à présent, la gestion du code asynchrone était gérée du côté des bibliothèques, les plus connues étant Amp, ReactPHP et Swoole. Chaque solution avait implémenté les logiques nécessaires à leur sauce. Avec l’arrivée des fibres dans le langage, les cartes sont rebattues et chacun devra apporter des modifications pour profiter de la partie native. D’ailleurs ReactPHP et Amp se sont associés pour écrire une couche d’abstraction nommée Revolt.

new dans le constructeur et des constantes finales

Les constantes finales ne peuvent pas être redéfinies dans une classe enfant (mais qui utilise l’héritage ???) et il est possible d’intégrer des new directement dans le constructeur.

class A {
  private final const A = "toto";

  public function __construct(private DatetimeImmutable $now = new DateTimeImmutable()){};
}

class B extend A{
  private final const A = "tata"; //Fatal error: B::A cannot override final constant A::A
}

Des performances en hausse

À chaque version, des optimisations sont trouvées et il en résulte de meilleurs résultats sur différents comparatifs. Cette version ne déroge pas à la règle. Un récent comparatif sur des temps de traitement d’une série de 250 requêtes trouve un temps de réponse diminué d’une vingtaine de pourcents pour une application Symfony ou Laravel et une poignée de pourcents pour un site Wordpress.

Pour la suite

Pour ceux qui tournent sur du PHP 7.4, il va falloir songer à passer en version 8.0 dans l’année. Pour rappel, une version est maintenue pendant trois ans (deux ans de maintenance active, un an de maintenance de sécurité). Pour cela, il faut baisser les seuils d’alerte au minimum, corriger ce qui provoque les bouts de code concernés par des alertes à la main ou automatiquement avec des outils du genre Rector.

À l’heure de la rédaction de ces lignes, peu de choses seront incluses dans la prochaine version, mais on peut déjà voir que cela ne sera toujours une somme de choses pour rendre le langage plus cohérent, de suppression de possibilités pour écrire des choses atroces, de simples utilitaires pour ne pas réinventer la roue, etc.

Les changements au niveau de la communauté

PHP est un langage communautaire, à ma connaissance, il n’y a pas d’entreprise qui emploie des personnes pour travailler à plein temps sur le langage. Le langage évolue donc au gré des volontés diverses et variées de proposer des nouvelles fonctionnalités et de les implémenter. Globalement, l’évolution et la maintenance du langage ne tient qu’à une poignée de motivé(e)s. Comme pour la plupart des projets communautaires, toute aide est la bienvenue que ce soit sous la forme de traduction, de documentation, de rapports de bug, pour rajouter du code c’est un poil plus compliqué, car il faut être familier avec le C à la sauce PHP !

Migration progressive sur Github

L’infrastructure vieillissante du projet arrivant au bout de sa vie et un incident de sécurité ce printemps ont poussé à stopper les contributions sur le service git du projet. Alors que le dépôt sur Github servait de miroir, il est devenu la source principale. La gestion des bugs va également se déplacer au même endroit.

Création de la fondation PHP

Jusqu’à présent il n’y avait aucune structure officielle chapeautant le projet et rare ont été les personnes payées pour développer le langage. Ces derniers temps ce nombre ne s’élevait qu’à deux, ce qui pour un langage aussi utilisé que PHP est surprenant, voire désolant. L’un des deux principaux développeurs du projet (Nikita Popov) tant au niveau du code, que des discussions autour des évolutions prévoit de réduire la voilure. Depuis trois ans, il était rémunéré par JetBrains pour travailler sur PHP. Cette fin d’engagement a poussé différentes personnes à finaliser la mise en place d’une fondation afin de supporter financièrement des contributeurs. Vous trouverez plus de détails dans cette annonce. C’est donc une très bonne nouvelle et il faut espérer que les dons des entreprises et des particuliers permettront d’intégrer, de diversifier et consolider le socle des contributeurs.

Aller plus loin

  • # anglicisme

    Posté par  . Évalué à 9 (+8/-0).

    rendre le langage plus consistant,[…]

    Il s'agit de rendre PHP cohérent, ici, et non consistant.

  • # re: La version 8.1 de PHP et création de la fondation PHP

    Posté par  (site Web personnel) . Évalué à 10 (+10/-1).

    Merci pour la dépêche complète et soignée.

    Je suis perplexe devant PHP. Le PHP de mes premières années (jusqu'à PHP5) semble tellement simple comparé au PHP d'aujourd'hui. J'avais l'impression d'avoir un langage de script/template à mi-chemin entre C et Java.

    Depuis, il y a des \ partout, les fonctions simples sont remplacées par des classes, la syntaxe s'est complexifiée pour exprimer des choses qu'on fait bien plus simplement en Python.

    On dirait la loi du C++ : tout langage tends à devenir si complexe qu'on ne peut qu'y être dévouée pour le maîtriser.

    Seul C et SH restent des langages simples et stables.

    Suis-je le seul à ressentir ça ?

    Pour autant, je reconnait que PHP est un phénix ayant survécu à une mort promise. Sa force doit être certainement sa faiblesse, à savoir que c'est un langage de template à la base. Donc très accessible. Dur de rivaliser avec la simplicité d'un index.php sur un FTP. Suffit de comparer avec les usines à gaz pour pousser un Gemfile ou un Pipfile dans un PaaS !

    • [^] # Re: re: La version 8.1 de PHP et création de la fondation PHP

      Posté par  (site Web personnel) . Évalué à 7 (+6/-0). Dernière modification le 03/12/21 à 13:23.

      J'aurais une vision plus mitigée en prenant en compte la notion de compatibilité ascendante qui reste quand même assez importante sur PHP.

      Il reste possible dans les dernières versions de créer des scripts très réduits de la même manière qu'on pouvait le faire avec PHP 3. La plupart des scripts écrits de cette manière restent d'ailleurs totalement fonctionnels sans changement malgré leur âge.

      Quand par contre on cherche à faire une application complexe, robuste, et ce, sans réinventer la roue en permanence, alors oui les apports des dernières versions sont particulièrement appréciables.

      Les namespaces par exemple (les \ que tu mentionnes), ont émergé par besoin et ont été longtemps implémentés par des bidouillages peu lisibles par chaque bibliothèque (class MyVendor_MyLib_MyPackage_MySomething_EventuallyMyClass). Mais ils restent totalement optionnels si le développeur ne souhaite pas les utiliser… à condition qu'il ne dépende pas de packages Composer évidemment.

    • [^] # Re: re: La version 8.1 de PHP et création de la fondation PHP

      Posté par  . Évalué à 4 (+2/-0).

      Perso, j'ai du code PHP 5 qui fonctionne encore (faut dire que c'est assez simple et surtout n'utilisais pas de choses dépréciées ou exotérique ni d'astuces non documentées)
      Après, comme toi, je suis un peu perplexe et c'est normal : je n'utilise plus vraiment le langage et donc ne subis pas ses évolutions. Cependant, les évolutions portent surtout sur l'aspect objet (et j'aime pas trop la syntaxe pour les espaces de noms) et des trucs pour le développement vraiment pro… En gros, ça se bonifie pour être à niveau de Python ou Ruby, et perdre sa mauvaise image. Il y a l'aspect sureté du code et performance sur lesquels il n'a pas à rougir face à la concurrence, et avec ça, côté compatibilité avec le vieux, j'ai pas vu d'autres langages faire aussi bien hormis PERL.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: re: La version 8.1 de PHP et création de la fondation PHP

      Posté par  (site Web personnel) . Évalué à 4 (+3/-0).

      Pour avoir un rappel des évolutions de PHP depuis PHP 7, je t'invite à lire l'article de blog que j'avais écrit sur le sujet : https://www.geek-directeur-technique.com/2021/10/17/de-php-7-a-php-8-retour-sur-cinq-ans-dinnovation

      Après, oui PHP s'est complexifié, dans le sens où il offre maintenant des fonctionnalités supplémentaires et des facilités d'écriture. Mais beaucoup d'évolutions sont à destination des développeurs de frameworks et ne sont pas forcément destinées aux développeurs applicatifs. De manière générale, tu utilises ce que tu veux utiliser… la limite étant l'utilisation de code externe.

      La courbe d'apprentissage de PHP reste assez douce quand on vient de langages comme le C ou la Java. Comme c'est un langage qui n'a pas grand-chose à envier aux autres sur le plan des fonctionnalités et des performances, si tu as déjà les bases ça peut valoir la peine de te tenir à jour des évolutions du langage de temps en temps. Ce sera beaucoup moins violent que de se former à un autre langage moderne.

      Là où je suis d'accord, c'est que par rapport au C, on est sur un rythme très différent. Mais es-tu au courant des nouveautés des normes C11 et C18 ? J'avoue que même si je continue à coder en C (rarement mais ça m'arrive, la sensation de toute puissance quand on sait ce qu'on fait avec la mémoire est assez géniale), je suis resté au C99… si j'ai besoin de “plus” (plus de fonctionnalités ou plus de simplicité), je vais vite passer au PHP.

  • # Developpeur PHP mais pour combien de temps

    Posté par  . Évalué à 6 (+5/-0).

    Je suis un développeur PHP (et C entre autre) mais aujourd'hui, PHP n'a clairement pas ma préférence. PHP a su évoluer et s'améliorer, pour autant j'ai jamais aimé le coup du '$' pour les variables.

    Ce n'est pas de sa faute, mais je préfère maintenant le remplacer
    * par Julia (idéalement car peu connu, donc difficile a imposer dans un projet)
    * par Go (plus performant, aussi simple et pas sensible aux évolutions du langage une fois compilé)
    * par Python pour ses modules hyper-puissants (Je pense a SymPy) même si j'aime pas sa lenteur et…

    Je pense malgré tout que je n'abandonnerai pas PHP de si tôt, il a de sérieux avantages malgré tout (simplicité, utilisable en CLI comme en Web, environnement complet avec une bonne comunauté… ).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.