Les nouveautés de PHP8

• Date de proposition : septembre 2019.
• Auteur de la proposition : Nikita Potov.
• Statut : implémenté !
• RFC : https://wiki.php.net/rfc/union_types_v2.
• Résultat des votes : 61 votes POUR et 5 votes CONTRE. N’hésitez pas à donner votre point de vue sur le forum !

Depuis la version 7.4 de PHP, vous pouvez préciser le type de toute propriété d’une classe. Si vous ne le précisez pas, comme en version 7.3 et précédentes, alors cette propriété accepte n’importe quel type, avec tous les risques que cela peut entraîner. Si le type est précisé et que vous ne le respectez pas, PHP provoque une erreur. Cette RFC « Union type » permet à une propriété de ne plus accepter un seul type défini, mais plusieurs.

Admettons que vous vouliez que la propriété de votre classe soit un entier ou nombre flottant, auparavant, vous n’aviez d’autre choix que de le noter en commentaire et d’espérer que les développeurs respectent vos contraintes. Votre objet ressemblait à cela :

class Nombre {
    /**
     * @var int|float $nombre
     */
    private $nombre;
 
    /**
     * @param int|float $nombre
     */
    public function setNombre($nombre)
    {
        $this->nombre = $nombre;
    }
 
    /**
     * @return int|float
     */
    public function getNombre() 
    {
        return $this->nombre;
    }
}

Les plus exigeants pouvaient aussi ajouter un validateur dans le setter et générer des exceptions. Désormais, en PHP 8, ce sera beaucoup plus simple. Vous pourrez déclarer un ensemble de types en les séparant par une barre verticale, le caractère « pipe » : | .

class Nombre {
    private int|float $nombre;
 
    public function setNombre(int|float $number): void
    {
        $this->nombre = $nombre;
    }
 
    public function getNombre(): int|float
    {
        return $this->nombre;
    }
}

Pas mal ! J’y vois un intérêt immédiat pour les types décimaux de Doctrine. Ce type décimal est un nombre décimal quand il est stocké en base de données avec un nombre précis de chiffres avant et un autre nombre précis de chiffres après la virgule. Ce type n’existant pas en PHP, pour éviter tout problème d’arrondi avec les nombres réels, Doctrine convertit ce nombre flottant en chaîne de caractères, avant de le renvoyer à votre modèle de données. Le développeur gère donc tantôt une chaîne, tantôt un nombre flottant. Les types à choix multiples sont une excellente solution pour ce cas précis.

• Date de proposition : janvier 2019.
• Auteurs : Dmitry Stogov et Zeev Suraski.
• Statut : accepté et implémenté dans certaines branches dédiées.
• RFC : https://wiki.php.net/rfc/jit.
• Votes : 50 votes POUR ; 2 votes CONTRE.

JIT est l’acronyme de « Just In Time » : compilation à la volée en français. Cette optimisation a été plusieurs fois repoussée :

• les gains de performance n’étaient pas assez importants ;
• le code devenait trop complexe à développer et à maintenir ;
• il existait d’autres optimisations possibles avant celle-ci. (OPCache, par exemple.)

D’ailleurs, si vous regardez le détail des votes, le déploiement de JIT dans la version 7.4 avait été rejeté par les électeurs, quand bien même cette extension aurait été inscrite comme expérimentale : 18 votes POUR ; 36 votes CONTRE. Il faut dire que les enjeux sont importants.

À terme, l’administrateur du serveur pourra modifier dans le fichier de configuration un ensemble de paramètres pour activer ou non la compilation à la volée, changer la taille du cache, mais aussi certains déclencheurs. Je pensais au départ qu’il n’y aurait aucun impact dans le code, mais il semble que nous pourrons utiliser l’annotation « @jit », dans notre code pour cibler certaines fonctions. D’ailleurs, à mon sens, cela ne devrait pas être une annotation. Cela devrait respecter cette autre nouveauté de PHP 8 : les attributs.

Alors, le gain de performance ? Eh bien, ça semble très prometteur. Voici les fichiers de benchmark utilisés, un par langage. Le résultat de ce benchmark est passé de 46 ms en version 7.4 à 11 ms en version 8 ! Oui PHP 8, dans le cadre de ce test, est quatre fois plus rapide. Je précise que c’est bien : dans le cadre de ce test. Certes, les dés ne sont pas truqués comme pour les essais des moteurs diesel du constructeur Volkswagen, nous ne savons pas ce qu’il en sera pour la moyenne de tous les processus, mais c’est très prometteur !

D’autres tests ont été effectués, les plus mauvais parlent d’un gain de 5 %, d’autres d’un gain de 30 %, d’autres révèlent qu’on passe d’une moyenne de 320 ms à 140 ms. Les mauvaises langues diront que le gain est presque nul dans certains cas. D’autres comprendront qu’aucune perte n’a été mesurée, alors que cela arrive souvent : toucher un compilateur peut améliorer certains calculs au détriment d’autres. C’est arrivé pour certaines versions d’autres compilateurs. Je ne les cite pas, car je ne suis pas dans un esprit de comparaison, d’autant que le gain global était très satisfaisant. Après tout, il est tout à fait acceptable de perdre des points de performances sur certains calculs quand d’autres gains sont attendus. D’ailleurs, c’est ce que beaucoup de développeurs font quand ils implémentent un système de cache. Ils savent perdre du temps à la création du cache, pour en gagner par la suite. Le plus important, à mes yeux, est que les développeurs de PHP gardent toujours à l’esprit les objectifs de PHP : rendre des pages web, le plus rapidement possible.

D’autres enjeux peuvent entrer en ligne de compte. Restons sur PHP pour éviter toute polémique. La version 5.0 était plus lente que la version 4.4. Une honte selon certains ! En réalité, la version 5.0 apportait beaucoup de fonctionnalités supplémentaires par rapport à la version 4.4. Cette perte n’avait pas été seulement acceptée, elle avait été anticipée. Les développeurs auraient pu ne pas déployer cette version et attendre la version 5.1 qui réglait la plupart des latences. Cela n’a pas été leur choix. À mon sens, ils ont eu bien raison, les nouveautés de la version 5.0 étaient attendues et les mises à jour de la version 4.4 étaient toujours assurées. Cela laissait donc le choix au chef de projet de privilégier ce qu’il fallait en fonction des desiderata de ses clients.

N’hésitez pas à faire vos propres tests grâce à cette version de PHP compilée avec JIT : https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190315/.

Voici le code pour effectuer le même test de Mabdelbrot : https://gist.github.com/dstogov/12323ad13d3240aee8f1.

<?php
define("BAILOUT",16);
define("MAX_ITERATIONS",1000);

class Mabdelbrot
{
    function __construct()
    {
        $d1 = microtime(1);
        for ($y = -39; $y < 39; $y++) {
            for ($x = -39; $x < 39; $x++) {

                if ($this->iterate($x/40.0,$y/40.0) == 0) 
                    echo("*");
                else
                    echo(" ");

            }
            echo("\n");
        }
        $d2 = microtime(1);
        $diff = $d2 - $d1;
        printf("\nPHP Elapsed %0.3f\n", $diff);
    }


    function iterate($x,$y)
    {
        $cr = $y-0.5;
        $ci = $x;
        $zr = 0.0;
        $zi = 0.0;
        $i = 0;
        while (true) {
            $i++;
            $temp = $zr * $zi;
            $zr2 = $zr * $zr;
            $zi2 = $zi * $zi;
            $zr = $zr2 - $zi2 + $cr;
            $zi = $temp + $temp + $ci;
            if ($zi2 + $zr2 > BAILOUT)
                return $i;
            if ($i > MAX_ITERATIONS)
                return 0;
        }
    }
}

ob_start();
$m = new Mabdelbrot();
ob_end_flush();

Vous pouvez observer dans l’image suivante les résultats sur mon ordinateur de développement. Notez que j’ai remplacé tous les caractères par des espaces, pour vous permettre de comparer les résultats sur la même capture d’écran !

• Date : mars 2020.
• Auteur : Nikita Popov.
• Statut : accepté. Cela sera testable, quand le statut sera : implémenté.
• Votes : 46 votes POUR ; 10 votes CONTRE.
• RFC : https://wiki.php.net/rfc/constructor_promotion.

Les langages objet sont particulièrement verbeux. Par exemple, en PHP, pour écrire un simple objet respectant le patron de conception DTO, il faut écrire quelque chose de la sorte :

class MessageDTO
{
    public string $titre;

    public string $contenu;

    public DateTimeImmutable $publication;

    public function __construct(
        string $titre, 
        string $contenu, 
        DateTimeImmutable $publication
    ) {
        $this->titre = $titre;
        $this->contenu = $contenu;
        $this->publication = $publication;
    }
}

Désormais, en PHP 8, voici un code au résultat et aux propriétés exactement identiques, mais dont le code est grandement simplifié :

class MessageDTO
{
    public function __construct(
        public string $titre,
        public string $contenu,
        public DateTimeImmutable $publication
    ) {}
}

C’est plus clair, non ? En ajoutant le mot public devant un argument, PHP crée une propriété publique correspondante. Quelle bonne nouvelle ! Le code des classes va y gagner en lisibilité.

$message = new MessageDTO('titre','contenu du message', new DateTimeImmutable());
echo "\n".$message->titre;
echo "\n".$message->contenu;
echo "\n".$message->publication->format('d/m/Y H:i:s');

En attendant de tester, concentrons-nous sur le fonctionnement. En fait, en arrière-plan, PHP va transformer le code simplifié en un code plus verbeux. Le constructeur va donc promouvoir les paramètres déclarés comme publics en propriétés publiques.

Malheureusement, je n’ai pas l’impression que cela fonctionnera pour les paramètres déclarés comme privés ou protégés. J’avais espéré aussi que nous pourrions simplifier les classes qui respectent le patron de conception des entités. (Les propriétés sont privées ou protégées et un getter et un setter publics permettent respectivement de les récupérer et de les modifier.)

• Date : mars 2020.
• Auteurs : Benjamin Eberlei, Martin Schröder.
• Statut : accepté.
• RFC : http://wiki.php.net/rfc/attributes_v2.
• Implémentation : https://github.com/php/php-src/pull/5394.
• Votes : 51 votes POUR ; un vote CONTRE.

Si je parlais d’annotations au lieu d’attributs, cette nouveauté serait peut-être plus parlante pour vous. En fonction des langages, le même concept a plusieurs noms :

• annotations en Java, mais aussi en PHP (ce fameux @ dans les commentaires) ;
• attributs en C++ ou en Rust ;
• décorateurs en Python.

Pour rester fidèle au nom de cette RFC, je vais m’en tenir au terme attribut dans la suite de cet article. Plusieurs communautés de développeurs PHP ont repris les principes des attributs, un pseudolangage dans les commentaires préfixé par @. Les développeurs utilisant PHPDoc ou Doctrine utilisent les attributs. Certains sans le savoir, comme dirait M. Jourdain.

Bref, si les développeurs étaient quasiment unanimes pour le développement de cette RFC, ils étaient moins tranchés pour choisir le symbole de l’attribut :

• 41 ont voté pour les doubles marqueurs inférieurs et supérieurs : << Attribut >> ;
• 12 ont voté pour l’arobase : @Attribut.

Alors, dans les faits, qu’est-ce que cela donne ? Eh bien, j’ai repris un exemple de la RFC pour l’implémentation d’une entité Doctrine. J’ai scindé l’exemple en deux parties de code. Le premier code ne devrait pas vous surprendre, il s’agit de ce qui existait déjà. Le second présente sa future implémentation avec PHP 8. Au passage, remarquez à la ligne 2 : Doctrine nomme bien cela un attribut depuis longtemps !

<?php
use Doctrine\ORM\Attributes as ORM;
use Symfony\Component\Validator\Constraints as Assert;
 
/** @ORM\Entity */
class User
{
    /** @ORM\Id @ORM\Column(type="integer"*) @ORM\GeneratedValue */
    private $id;
 
    /**
     * @ORM\Column(type="string", unique=true)
     * @Assert\Email(message="The email '{{ value }}' is not a valid email.")
     */
    private $email;
 
    /**
     * @ORM\Column(type="integer")
     * @Assert\Range(
     *      min = 120,
     *      max = 180,
     *      minMessage = "You must be at least {{ limit }}cm tall to enter",
     *      maxMessage = "You cannot be taller than {{ limit }}cm to enter"
     * )
     */
    protected $height;
 
    /**
     * @ORM\ManyToMany(targetEntity="Phonenumber")
     * @ORM\JoinTable(name="users_phonenumbers",
     *      joinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")},
     *      inverseJoinColumns={@ORM\JoinColumn(name="phonenumber_id", referencedColumnName="id", unique=true)}
     *      )
     */
    private $phonenumbers;
}

<?php
use Doctrine\ORM\Attributes as ORM;
use Symfony\Component\Validator\Constraints as Assert;
 
<<ORM\Entity>>
class User
{
    <<ORM\Id>><<ORM\Column("integer")>><<ORM\GeneratedValue>>
    private $id;
 
    <<ORM\Column("string", ORM\Column::UNIQUE)>>
    <<Assert\Email(array("message" => "The email '{{ value }}' is not a valid email."))>>
    private $email;
 
    <<Assert\Range(["min" => 120, "max" => 180, "minMessage" => "You must be at least {{ limit }}cm tall to enter"])>>
    <<ORM\Column(ORM\Column::T_INTEGER)>>
    protected $height;
 
    <<ORM\ManyToMany(Phonenumber::class)>>
    <<ORM\JoinTable("users_phonenumbers")>>
    <<ORM\JoinColumn("user_id", "id")>>
    <<ORM\InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)>>
    private $phonenumbers;
}

Ne faites pas trop attention à la coloration syntaxique. L’éditeur est perdu. Au début, je préférais éviter le changement. J’aimais bien ces arobases, mais je dois reconnaître que la solution retenue présente plusieurs avantages  :

• le format @Attribut n’a pas de délimiteur de fin d’attribut, quoique le point-virgule était une option ;
• les symboles [[ Attributs ]] entrent en conflit avec la syntaxe courte des tableaux.

La RFCPHP RFC: Attributes v2 présente d’ailleurs un débat intéressant s’appuyant sur des critiques argumentées. N’hésitez pas à utiliser ce sujet de notre forum pour donner votre préférence !

Les instances de cette classe WeakMap s’utilisent tels des tableaux dont l’index n’accepte rien d’autre qu’un objet.

Exemple d'utilisation d'une WeakMap

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

$map = new WeakMap;
$obj = new stdClass;
$map[$obj] = 42;

var_dump($map);
// object(WeakMap)#1 (1) {
//   [0]=>
//   array(2) {
//     ["key"]=>
//     object(stdClass)#2 (0) {
//     }
//     ["value"]=>
//     int(42)
//   }
// }

$map n’est pas un tableau, comme on pourrait le croire à la ligne 3. Il s’agit bien d’un objet instancié à la ligne 2.

Ce qui est intéressant avec cette classe, c’est que la destruction de l’objet $obj détruit aussi la valeur 42 qui y avait été associée à la troisième ligne. Cette une faiblesse volontaire de cette association, d’où le nom WeakMap.

unset($obj);
var_dump($map);
// object(WeakMap)#1 (0) {}

C’est à la fois un avantage et un inconvénient :

• un avantage, car la destruction de l’objet entraîne la suppression de la valeur associée :

  • cela évite toute fuite de mémoire,
  • chaque instance de la classe reste ainsi itérable ;

• un désavantage, car il n’y a donc pas de possibilité d’énumérer les clés. Les conséquences sont nombreuses :

  • on ne peut pas sérialiser l’objet,
  • seuls des objets peuvent servir de clé,
  • ajouter un élément avec [] génère une erreur.

À la différence de WeakReferenceDocumentation de la classe WeakReference, toute instance de cette classe peut-être clonée.

Le fichier de test de cette classe est particulièrement parlant.

En version 7, une méthode pouvait déjà retourner les types « self » et « static ». En revanche, si l’on pouvait préciser le type « self », on ne pouvait pas préciser un résultat de type « static ». Ça explosait. Ce sera désormais possible en PHP 8, comme le précise cette RFCPHP RFC: Static return type.

<?php
class A {
    // Le mot-clé self en fin de déclaration de méthode NE génère PAS une erreur en PHP7.
    public static function getSelf(): self
    {
        return new self();
    }

    // Le mot-clé static en fin de déclaration de méthode GÉNÈRE une erreur en PHP7 et n’en générera plus en PHP8.
    public static function getStatic(): static
    {
        return new static();
    }
}

//Pour ceux qui ignorent la différence entre self et static, voici un exemple :
class B extends A {}

echo get_class(B::getSelf());   // A
echo get_class(B::getStatic()); // B
echo get_class(A::getSelf());   // A
echo get_class(A::getStatic()); // A

Cela ne va pas révolutionner le monde, mais c’était un manque assez troublant.

Restons dans les types. Actuellement, les types primaires possibles sont les suivants :

• array ;
• bool ;
• callable ;
• int ;
• float ;
• null ;
• object ;
• resource ;
• string.

Cette RFCPHP RFC: Mixed Type v2 décrit l’implémentation du nouveau type « mixed ». En version 8, ce code ne génèrera plus d’erreur :

<?php
class Message {
    
    protected mixed $sujet;
    
    public function getSujet(): mixed
    {
        return $this->sujet;
    }
    
    public function setSujet(mixed $sujet): self
    {
        $this->sujet = $sujet;
        
        return $this;
    }
}

Dans le cas d’un héritage de la classe Message, il est intéressant de savoir que :

• les types des paramètres sont contravariants ;
• les types des résultats sont covariants ;
• les types des propriétés sont invariants.

Voici quelques exemples avec la classe Sms qui hérite de la classe Message pour mettre en évidence les différences entre contravariance, covariance et invariance :

<?php
class Message {    
    public function setSujet(string $sujet) {}
}

class Sms extends Message
{
    // Les types des paramètres sont contravariants, je PEUX étendre le type. (string to mixed)
    public function setSujet(mixed $value) {}
}

class Message {
    public function setSujet(mixed $sujet) {}
}

class Sms extends Message
{
    // Les types des paramètres sont contravariants, je NE peux PAS préciser le type (mixed to string)
    public function setSujet(string $value) {} //Plantage
}

<?php
class Message {
    
    public function setSujet(): mixed {}
}

class Sms extends Message
{
    // Les types des résultats sont covariants, je PEUX préciser le type (mixed to string).
    public function setSujet(): string {}
}

class Message {
    
    public function setSujet(): string {}
}

class Sms extends Message
{
    // Les types des résultats sont covariants, je NE peux PAS élargir le type (string to mixed)
    public function setSujet(): mixed {} //Plantage
}

<?php
class Message
{
    public mixed $titre;
    public int $messages;
    public $publication;
}
 
class Sms extends Message
{
    // Les types des propriétés sont invariants, je NE peux PAS préciser passer de mixed à string
    public string $titre; //Plantage

    // Les types des propriétés sont invariants, je NE peux PAS supprimer le type de titre, même pas mixed.
    public $titre; //Plantage

    // Les types des propriétés sont invariables, je NE peux PAS étendre passer le type de int à mixed
    public mixed $messages; //Plantage
    
    // Les types des propriétés sont invariants, je NE peux PAS ajouter un type à publication, même pas mixed.
    public mixed $publication; //Plantage
}

II-H-1. Le mot-clé throw devient une expression▲

<?php
// Si la condition n'est pas respectée, alors je génère une exception
$condition || throw new Exception();
$condition or throw new Exception();

// Si la condition est respectée, alors je génère une exception
$condition && throw new Exception();
$condition and throw new Exception();

// Les fonctions fléchées n'acceptant que des expressions simples, le code suivant plantait. « Mais ça, c'était avant ! »
$callable = fn() => throw new Exception();
 
// Test simplifié : la valeur est non nulle, sinon je génère une exception.
$value = $nullableValue ?? throw new InvalidArgumentException();
 
// Test simplifié : la valeur est vraie (au sens non strict), sinon je génère une erreur
$value = $falsableValue ?: throw new InvalidArgumentException();
 
// Test simplifié : si le tableau n'est pas vide, je le réinitialise, sinon je génère une exception de type argument invalide.
$value = !empty($array)
    ? reset($array)
    : throw new InvalidArgumentException();

II-H-2. Fin de l’obligation d’affecter une variable à l’exception levée▲

<?php
//Avant PHP 8
try {
    // Cette fonction génère une exception
    fonctionGenerantUneException();
} catch (Exception $variableQuiNeSertPas) { 
    echo 'Un message d’erreur qui n’utilise pas l’exception';
}


// En PHP 8.0
try {
    // Cette fonction génère une exception
    fonctionGenerantUneException();
} catch (Exception) { //C’est plus clair, non ?
    echo 'Un message d’erreur qui n’utilise pas l’exception';
}

II-I-1. La nouvelle interface Stringable▲

II-I-2. La fonction str_contains▲

<?php

str_contains('abc', 'a'); // true
str_contains('abc', 'd'); // false
 
// les arguments peuvent contenir une chaîne vide.
str_contains('abc', '');  // true
str_contains('', '');     // true
str_contains('', 'abc');  // false

// ce qui présente un peu plus d’intérêt quand un argument est une variable dont on ignore la valeur
str_contains('abc', $variable);
str_contains($variable, 'a');

II-I-3. Les fonctions str_start_with et str_end_with▲

$str = "debutMilieuFin";
str_starts_with($str, "deb") //true
str_starts_with($str, "Deb") //false - sensibilité à la casse
str_ends_with($str, "Fin")   //true 
str_ends_with($str, "fin")   //false - sensibilité à la casse
 
// avec des chaînes vides:
str_starts_with("a", "") //true
str_starts_with("", "")  //true
str_starts_with("", "a") //false
str_ends_with("a", "")   //true
str_ends_with("", "")    //true
str_ends_with("", "a")   //false

II-J-1. get_debug_type▲

Cette nouvelle fonction me semble prometteuse. La fonction gettype présente un défaut majeur, elle manque de précision, elle ne retourne pas les types natifs de PHP, elle ne précise pas le nom de la classe d’un objet, seulement le fait que c’est un objet.

Il y a fort à parier que PHPUnit recodera ses assertions statiques qui évaluent les types de données avec cette fonction. Ayant contribué à l’écriture de nombreux tests en PHP et en Symfony, j’y vois également un autre intérêt : cette fonction va aider les équipes de testeurs pour vérifier que les ressources ouvertes par les développeurs sont correctement refermées.

On remarquera que PHP gagne en cohérence. Les nouvelles fonctions respectent la nouvelle graphie : chaque mot est séparé par un tiret bas. J’aurais néanmoins profité de cette RFC pour créer un nouvel alias get_type de la fonction gettype et j’aurais demandé la dépréciation de gettype.

II-J-2. fdiv▲

var_dump(fdiv(10, 3));     //float(3.3333333333333)
var_dump(fdiv(10., 3.));   //float(3.3333333333333)
var_dump(fdiv(-10., 2.5)); //float(-4)
var_dump(fdiv(10., -2.5)); //float(-4)

var_dump(fdiv(10., 0.));   //float(INF)
var_dump(fdiv(10., -0.));  //float(-INF)
var_dump(fdiv(-10., 0.));  //float(-INF)
var_dump(fdiv(-10., -0.)); //float(INF)

var_dump(fdiv(INF, 0.));   //float(INF)
var_dump(fdiv(INF, -0.));  //float(-INF)
var_dump(fdiv(-INF, 0.));  //float(-INF)
var_dump(fdiv(-INF, -0.)); //float(INF)

var_dump(fdiv(0., 0.));    //float(NAN)
var_dump(fdiv(0., -0.));   //float(NAN)
var_dump(fdiv(-0., 0.));   //float(NAN)
var_dump(fdiv(-0., -0.));  //float(NAN)

var_dump(fdiv(INF, INF));  //float(NAN)
var_dump(fdiv(INF, -INF)); //float(NAN) 
var_dump(fdiv(-INF, INF)); //float(NAN)
var_dump(fdiv(-INF, -INF));//float(NAN)

var_dump(fdiv(0., INF));   //float(0)
var_dump(fdiv(0., -INF));  //float(-0)
var_dump(fdiv(-0., INF));  //float(-0)
var_dump(fdiv(-0., -INF)); //float(0)

var_dump(fdiv(NAN, NAN));  //float(NAN)
var_dump(fdiv(INF, NAN));  //float(NAN)
var_dump(fdiv(0., NAN));   //float(NAN)
var_dump(fdiv(NAN, INF));  //float(NAN)
var_dump(fdiv(NAN, 0.));   //float(NAN)

II-J-3. get_resource_id▲

Cette RFCPHP RFC: Allow trailing comma in parameter list autorise une virgule à la fin des paramètres d’une fonction pour un mode de fonctionnement identique aux arguments d’un tableau ou d’une liste.

class Uri {
    private function __construct(
        ?string $scheme,
        ?string $query,
        ?string $fragment, // Cette virgule faisait tout planter avant PHP 8
    ) {
        $array = [
            $scheme,
            $query,
            $fragment, // Alors qu’ici c’était accepté !   
        ];
    }
}

Une autre nouveauté, l’extension ext-json n’est plus une extension, son code est intégré au noyau de PHP. Les développeurs n’auront plus besoin de vérifier sa présence. Pour le coup, je me demande comment nous allons gérer cela avec composer, il va falloir que composer considère que la version 8 possède cette extension, sinon on va au-devant de quelques problèmes pour les bibliothèques qui seront utilisables dans des projets PHP 7 et PHP 8.

Si la première clé de votre tableau était un nombre négatif, la clé suivante était zéro. Faites le test en utilisant array_fill. Cette RFC change la donne, la clé suivante sera toujours n+1, même si n est négatif.

La RFC donne plusieurs exemples qui vont vous éclairer sur les changements et leurs impacts.

$a = array_fill(-2, 3, true);
$b = [-2 => true, true, true];
$c = ["string" => true, -2 => true, true, true];
unset($c["string"]);
$d[-2] = true;
$d[] = true;
$d[] = true;

Avant PHP 8, toutes ces variables a, b, c et d résultent en un tableau dont les clés d’index sont les suivantes :

• -2, on pouvait s’y attendre ;
• 0, cette fois c’est plus étonnant ;
• 1, là encore on pouvait s’y attendre.

En PHP 8, grâce à cette RFC, les clés s’incrémentent à partir de -2 :

• -2 ;
• -1, voilà qui est plus cohérent ;
• 0.

Cette modification était nécessaire. Néanmoins, son impact sera sans aucun doute l’une des plus pernicieuses. Si une fonction disparaît, il est facile de la rechercher dans son code et de la remplacer. Pour ce qui concerne des index négatifs qu’on incrémente, c’est plus complexe à rechercher dans le code source.

Si PHP va y gagner en cohérence, certains développeurs vont néanmoins avoir des surprises et vont devoir revoir leur code ! D’ailleurs, j’ai quelques correctifs qui vont disparaître dans certains projets, car nous avions justement des bogues à cause de cette incrémentation étrange de PHP. Toutefois, pour aider à repérer le souci, les développeurs de PHP ont mis en place une dépréciation, mais soyez vigilant, cette dépréciation ne sera présente que dans la version 7.4 !

Le polymorphisme apporté par les traits est amélioré par cette RFCPHP RFC: Validation for abstract trait methods qui a d’ailleurs obtenu l’unanimité des auteurs. Elle valide les méthodes abstraites des traits selon les règles des types de paramètres qui doivent être identiques. (Ou contravariants dans le cas de mixed.)

trait T {
    abstract public function test(int $x);
}
 
class C {
    use T;
 
    // La ligne ci-dessous devrait planter, mais ce n’était pas le cas en PHP7
    public function test(string $x) {
        var_dump($x);
    }
}

Désormais, les types seront contrôlés. Par conséquent, on génère une incompatibilité rétroactive pour tous les codes qui utilisaient des traits, mais dont les méthodes avaient des signatures incorrectes. Cette rétro-incompatibilité est acceptable, car, en théorie, un développeur ne devrait pas laisser passer ce genre de bogues.

III-C-1. La configuration des remontées d’erreur▲

III-C-2. Changement de niveau pour certaines erreurs▲

<?php

function test($a = [], $b) {} // Ceci est déprécié.

function test2(Form $a = null, $b) {} // Ceci reste autorisé.

III-C-3. Les opérandes incorrects▲

<?php

var_dump([] % [42]); //Retourne int(0)

$c = new class{}; 
$c++; // Tout allait bien pour PHP !

$a = [42];
$a++; // Là encore, tout va bien, alors que cela ne devrait pas

Enfin ! Nous autres, Français et Allemands, n’allons plus rencontrer ce fichu bogue de reconversion ! Je m’explique.

La conversion d’un nombre flottant en chaîne de caractères sera désormais toujours indépendante de la locale comme proposé dans cette RFCPHP RFC: Locale-independent float to string cast. Pour nous, Français, l’impact sera substantiel. Il va surtout supprimer de nombreux problèmes de conversion et de reconversion.

<?php

//Alors qu'en anglais, tout marche bien !
setlocale(LC_ALL, "en_US");
$en = 42.245;
var_dump((string) $en);        // string(6) "42.245"
var_dump((float)(string) $en); // float(42.245) tout va bien
 
//En français, la double conversion fait perdre les chiffres après la virgule !
setlocale(LC_ALL, "fr_FR");
$fr = 42.245;
var_dump(       (string) $fr); // string(6) "42,245"
var_dump((float)(string) $fr); // float(42) ça fait mal !!! Je peux vous garantir que bon nombre d’applications perdent des centimes dans leur calcul de TVA dès lors qu’on touche à la locale.

//En PHP 8 tout restera indépendant de la locale !
var_dump((string) $fr);        // string(6) "42.245"
var_dump((float)(string) $fr); // float(42.245) c'est mieux non ?

En fait, pour moi, c’était un bogue. J’aurais aimé que ce soit corrigé dans toutes les versions précédentes, mais l’équipe de développeur considère que c’est un changement fonctionnel qui casse la rétrocompatibilité et que cela ne peut donc être fait que lors d’une version majeure.

Voici une liste complémentaire. Cette liste n’est pas exhaustive.

• Comme nous l’avons vu dans le test de performance de Mabdelbrot, les méthodes avec le même nom que la classe ne sont plus traitées comme des constructeurs de classe. La méthode __construct doit être systématiquement utilisée, c’est la seule à être reconnue comme constructeur de classe.
• On ne peut plus appeler une méthode dynamique de la même façon qu’on le fait avec une méthode statique.
• Les conversions automatiques ne sont plus appelées.
• Accéder à des constantes non déclarées explicitement résulte en une exception de classe Error. Auparavant elles étaient interprétées comme une chaîne de caractères et généraient un avertissement.
• Le troisième argument de la fonction define ne peut plus être « true ». En conséquence, les noms des constantes sont toujours sensibles à la casse.

• Des fonctions sont supprimées :

  • __autoload ;
  • convert_cyr_string (sans dépréciation) ;
  • create_function ;
  • each ;
  • ezmlm_hash (sans dépréciation) ;
  • fgetss ;
  • get_magic_quotes_gpc ;
  • hebrevc (sans dépréciation) ;
  • money_format ;
  • restore_include_path (sans dépréciation).
• La fonction array_key_exists ne peut plus être utilisée avec des objets, vous devrez utiliser isset ou property_exists.
• Utiliser le mot-clé parent dans une classe qui n’en a pas résultera en une erreur fatale à la compilation.
• La concaténation de caractères n’est plus prioritaire sur les additions et les soustractions. C’était un vieux bug, sans doute lié à une confusion entre le point et le signe multiplié. Il est enfin corrigé. La RFCPHP RFC: Change the precedence of the concatenation operator ajoute une dépréciation en PHP 7.4 dès qu’une expression sans parenthèses contiendra successivement des signes « . », « + », « - ».