Archives de catégorie : Non classé

RFC: Interdire l’usage de plusieurs ‘default’ dans un ‘switch’

La RFC Make defining multiple default cases in a switch a syntax error partait du constat qu’il est aujourd’hui possible, en PHP, de placer plusieurs sections default dans un bloc switch.

Par exemple, en PHP 5.6, il est possible d’écrire ceci :

$a = 10;
switch ($a) {
    case 1:
        echo "cas 1\n";
        break;
    default:
        echo "premier default\n";
        break;
    default:
        // C'est dans ce second default qu'on passe, pas dans le premier
        echo "second default\n";
        break;
}

Dans ce cas, c’est la dernière section default qui est utilisée par PHP (là où, différences d’implémentation oblige, HHVM utilise la première).

Bien sûr, les discussions sur la mailing-list php-internals@afup ont montré que nous étions tous d’accord sur le fait qu’utiliser deux cas default dans une même structure switch n’a pas de sens et devrait donc être interdit et lever une erreur de syntaxe (en PHP 7). De plus, si PHP 5.7 sort un jour, cela devrait lever un avertissement E_DEPRECATED, pour préparer l’arrivée de PHP 7.  J’ai donc posté en ce sens sur internals@.

Cette RFC ayant été acceptée quelques jours après, PHP 7 sera plus cohérent sur ce point.

RFC: Opérateur null-coalesce ??

La RFC Null Coalesce Operator proposait d’introduire un nouvel opérateur ?? qui renverrait le résultat de sa première opérande s’il existe et est différent de NULL (en comparaison stricte), et celui de sa seconde opérande sinon.

Le constant de départ était que l’opérateur ?: introduit avec PHP 5.3 est pratique, mais pas parfait : il peut notamment entrainer des levées de notices si sa première opérande n’existe pas (ce qui force souvent à utiliser isset()).

Avec le nouvel opérateur ?? proposé par cette RFC, il deviendrait possible d’écrire quelque chose de ce type, qui ne lèverait pas de notice si $_GET['user'] n’existe pas :

$username = $_GET['user'] ?? 'nobody';

Les échanges que nous avons eu sur la mailing-list php-internals@afup ayant montré que notre avis était plutôt positif et qu’un tel opérateur apporterait une valeur à PHP, j’ai posté en ce sens sur internals@.

La RFC correspondante à été acceptée et ce nouvel opérateur ?? devrait arriver avec PHP 7 !

Notons que l’ajout d’un opérateur d’affectation ??= n’a pour l’instant pas été jugé utile. Il pourra, bien sûr, être ajouté dans le futur, s’il s’avère qu’il est nécessaire.

RFC: Integer Semantics

La RFC Integer Semantics visait à améliorer la cohérence de PHP entre plate-formes différentes, en implémentant les changements suivants :

  • NaN et Infinity seraient toujours égaux à 0 lorsque transtypés en entiers,
  • les décalages bit-à-bit d’un nombre négatif de bits seraient interdits,
  • le décalage bit-à-bit vers la gauche d’un nombre de bits supérieur à la taille d’un entier donnerait toujours 0,
  • et le décalage bit-à-bit vers la droite d’un nombre de bits supérieur à la taille d’un entier donnerait toujours 0 ou -1 (en fonction du signe)

En effet, aujourd’hui, une partie de ces manipulations a un comportement qui dépend de l’architecture et de la plate-forme sur laquelle tourne PHP.

Cette RFC vise donc à uniformiser les choses, en considérant que c’est le rôle d’un langage de haut-niveau comme PHP.

Les échanges que nous avons eu sur la mailing-list php-internals@afup montrant assez bien que nous étions globalement d’accord sur le fait qu’uniformiser le langage est une bonne chose et que les développeurs travaillant avec un langage de haut-niveau ne devraient pas avoir à se soucier du type de détails que veut corriger la RFC, j’ai posté en ce sens sur internals@.

Cette RFC a été acceptée quelques jours après et le comportement de PHP 7, pour ce qui concerne quelques cas spécifiques de manipulation d’entiers, devrait donc être moins dépendant de la plate-forme sur laquelle nos applications sont exécutées.