Archives de catégorie : Non classé

RFC: Group Use Declarations

Voici une RFC qui proposait d’ajouter une possibilité syntaxique à PHP, visant à faciliter l’utilisation d’espaces de noms : Group Use Declarations

Pour résumer, cette RFC partait du constat qu’écrire de multiples utilisations d’espaces de noms à plusieurs niveaux de profondeur entraîne une longueur de code impressionnante. Elle proposait donc l’introduction d’une nouvelle syntaxe, qui permettrait de réduire l’espace utilisé par ces use multiples et de rendre le code moins verbeux.

Par exemple, la portion de code suivante :

use Doctrine\Common\Collections\Expr\Comparison;
use Doctrine\Common\Collections\Expr\Value;
use Doctrine\Common\Collections\Expr\CompositeExpression;

Pourrait être ré-écrite de la manière suivante :

use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };

La RFC présente d’autres cas d’exemples, avec des « use ... as ...« , des use function ou const et montre que la syntaxe n’est pas limitée au dernier niveau de chaque espace de noms. Elle répond également à certains retours « communs » sur la proposition et sa syntaxe.

Les votes ont été ouverts le 11 février 2015 et pour être clôturés le 25 février, avec deux options :

  • « Oui », avec un \ à la fin de l’inclusion (le dernier : dans l’exemple reproduit plus haut ...\Expr\{} ),
  • « Oui », sans cet \ à la fin de l’inclusion — on aurait donc ...\Expr{}
  • Et, bien sûr, « non »

Les discussions que nous avons menées sur notre mailing-list ne nous ont pas permis d’atteindre un consensus et nous avons exprimé sur internals@ les principaux arguments auxquels nous étions arrivés.

Une majorité de 2/3 était requise pour son adoption, et cette RFC a été approuvée avec les résultats suivants :

  • Oui, avec un \ à la fin de l’inclusion : 32 voix;
  • Oui, sans le \ à la fin de l’inclusion : 7 voix;
  • Non : 19 voix

RFC: Remove the date.timezone warning

La RFC Remove the date.timezone warning partait du constat qu’il existe à l’heure actuelle une directive de configuration qui nécessite d’être définie afin de pouvoir lancer PHP sans erreur : date.timezone.

Lorsque cette directive n’est pas configurée, une erreur de type warning est générée par PHP, même si le moteur lui attribue une valeur par défaut (UTC).

Le but de cette RFC était de supprimer cette erreur, afin de pouvoir fournir à PHP une installation paramétrée complète par défaut. En effet, il apparaît que de nombreuses autres directives, bien plus sensibles notamment en terme de sécurité, sont d’ores et déjà configurées par défaut.

Il nous semblait que l’absence de configuration de cette directive devait à minima générer une erreur stricte, car elle impacte des fonctions de date très usitées (telle date()), d’autant que la zone par défaut est aujourd’hui définie de manière arbitraire. Nous avons donc répondu en ce sens sur internals@.

Néanmoins, avec 32 votes pour et 11 contre, cette RFC est passée et l’avertissement correspondant ne sera donc plus levé à partir de PHP 7.

RFC : Skipping optional parameters for functions

Ce n’est pas tout à fait la première fois que le sujet était évoqué, mais avec PHP 7 en approche, voici une RFC qui est revenue sur le devant de la scène : Skipping optional parameters for functions.

Aujourd’hui, lorsque l’on souhaite appeler une fonction qui accepte des paramètres optionnels, il est impératif de spécifier la valeur de tous les paramètres jusqu’au dernier qui nous intéresse — y compris si nous voulons utiliser la valeur par défaut des précédents.

Par exemple, considérons une fonction définie ainsi :

function ma_fonction($premier, $second = "world", $troisieme = false) {
    // la la la
}

Pour appeler cette fonction en passant true en dernier paramètre, en conservant la valeur par défaut pour le second, nous devons écrire ceci :

ma_fonction("Hello", "world", true);

Nous devons ainsi, lors de l’appel, passer la valeur "world" en second paramètre, alors que ce que nous voulions réellement faire était passer la valeur par défaut.

Cette RFC vise à répondre à cette problématique en permettant l’usage du mot-clef default à la place du passage de paramètres optionnels, pour ceux dont nous souhaitons utiliser la valeur par défaut.

L’exemple d’appel reproduit plus haut deviendrait donc :

ma_fonction("Hello", default, true);

Les votes pour cette RFC ont été ouverts le 08 février 2015 et clôturés le 21 février 2015.
Nous avons exprimé notre avis, négatif, sur internals@ : principalement, l’approche proposée nous semblait trop bidouille et nous préférerions bénéficier de paramètres nommés, même si ceux-ci n’arriveront probablement pas pour PHP 7.0 (et que la RFC citée ici n’était pas incompatible avec cette idée).
Cette RFC a finalement été rejetée, avec 17 votes « pour » et 27 votes « contre ».

RFC: Combined Comparison (Spaceship) Operator

Voici un autre sujet qui avait été discuté il y a quelques temps et qui est revenu en avant dernièrement, profitant certainement de l’approche de PHP 7, avec une mise à jour de la RFC au passage : Combined Comparison (Spaceship) Operator.

Cette RFC proposait d’ajouter un nouvel opérateur <=> de comparaison combinée — opérateur fréquemment appelé spaceship operator, de par sa forme. Cet opérateur, sur le modèle déjà utilisé pour des fonctions de comparaison comme strcmp(), retournerait trois valeurs :

  • 0 si les deux opérandes sont égaux,
  • 1 si l’opérande de gauche est plus grand que celui de droite
  • -1 si l’opérande de gauche est plus petit que celui de droite.

Il fonctionnerait sur tous les types de données génériques de PHP, en suivant les règles déjà en place pour <, > et ==.

Toute une série d’exemples est donnée dans la RFC, que ce soit pour des comparaison simples, des comparaisons un peu plus avancées, ou un usage avec des fonctions dépendant d’un tri utilisateur (cet opérateur simplifierait souvent l’écriture des fonctions de comparaison utilisées par ces fonctions).

Voici cependant un exemple basique :

// Integers
echo 1 <=> 1; // 0
echo 1 <=> 2; // -1
echo 2 <=> 1; // 1

Les votes ont été ouverts le 02 février 2015 pour être clôturés le 16 février 2015 et nous avons exprimé notre avis positif sur internals@.
Cette proposition a été acceptée avec 43 votes pour et 11 votes contre.

RFC: Fix « foreach » behavior

Voici une RFC à propos de la construction de boucle foreach : Fix « foreach » behavior

L’idée de départ de cette proposition était d’améliorer les performances de foreach (autour de 1% de gain pour certaines applications)… Mais, finalement, la RFC s’est plus orientée sur la correction d’incohérences et de comportement indéfinis.

Sans entrer dans les détails (ils sont plutôt techniques) sur cette page, il s’agit en somme d’essayer d’uniformiser quelques cas un peu tordus d’utilisation de foreach en cas d’itérations par valeurs et par références — la RFC liste ces cas, avec des exemples.

Cette RFC a été soumise à deux votes, ouverts le 05 févier 2015 pour être clôturés le 12 février 2015 :

  • le premier concernait directement la RFC, à une majorité des 2/3 des voix,
  • et le second demandait s’il faudrait cesser de modifier le pointeur tableau/objet dans foreach et nécessitait une majorité de 50% +1 voix.

Considérant que PHP 7 est une bonne occasion pour corriger des comportements étranges et apporter un peu de cohérence au langage, nous avons exprimé notre opinion, positive, sur internals@.
Les deux propositions de cette RFC ont été acceptées, toutes deux avec 34 voix pour 1 et une voix contre.

RFC: Removal of dead or not yet PHP7 ported SAPIs and extensions

Cette RFC n’a pas été énormément discutée sur internals@, ni sur notre mailing-list au départ, d’ailleurs… Ce qui signifie généralement que tout le monde est à peu près d’accord.

L’objectif de cette RFC était de supprimer de l’arbre de code de PHP :

  • Les SAPIs (les « modules » qui permettent, typiquement, de brancher PHP au sein d’un serveur Web) qui ne sont plus maintenues et probablement très peu utilisées
  • Des extensions qui ne sont plus maintenues (ou dont les dépendances ne le sont plus), éventuellement en les déplaçant vers PECL pour ceux qui en auraient encore besoin (à eux de les porter vers PHP 7, a priori)

Ceux qui portent cette RFC ont tenté de joindre les mainteneurs des extensions qui ne sont plus maintenues. Suite à quelques retours, quelques extensions ont été sauvées (la SAPI nsapi et l’extension interbase, par exemple).

La RFC s’est orientée sur un vote pour chacune des SAPIs (50% +1 pour supprimer) suivantes : sapi/aolserver, sapi/apache, sapi/apache_hooks, sapi/apache2filter, sapi/caudium, sapi/continuity, sapi/isapi, sapi/milter, sapi/phttpd, sapi/pi3web, sapi/roxen, sapi/thttpd, sapi/tux et sapi/webjames.

Et sur un vote pour chaque extension (50% +1 pour supprimer de PHP — quitte, éventuellement, à déplacer vers PECL si quelqu’un s’en charge) suivantes :

  • ext/imap
  • ext/mcrypt
  • ext/mssql
  • ext/pdo_dblib
  • ext/sybase_ct

Les votes ont été ouverts le 02 février 2015 pour être clôturés le 09 février 2015 et nous avons indiqué sur internals@ être pour la suppression de la quasi-totalité des points listés.
Les résultats sont les suivants :

SAPI Supprimer Conserver Résultat
sapi/aolserver 31 0 SAPI supprimée
sapi/apache 32 0 SAPI supprimée
sapi/apache_hooks 31 0 SAPI supprimée
sapi/apache2filter 23 1 SAPI supprimée
sapi/caudium 30 0 SAPI supprimée
sapi/continuity 28 0 SAPI supprimée
sapi/isapi 28 0 SAPI supprimée
sapi/milter 10 9 SAPI supprimée
sapi/phttpd 26 0 SAPI supprimée
sapi/pi3web 24 0 SAPI supprimée
sapi/roxen 23 0 SAPI supprimée
sapi/thttpd 25 0 SAPI supprimée
sapi/tux 25 0 SAPI supprimée
sapi/webjames 25 0 SAPI supprimée
ext/imap 14 19 Extension conservée
ext/mcrypt 15 18 Extension conservée
ext/pdo_oci et ext/oci8 n/a n/a Retiré du vote *
ext/mssql 17 3 Extension supprimée
ext/pdo_dblib 4 18 Extension conservée
ext/sybase_ct 17 1 Extension supprimée

 (*) Les extensions ext/pdo_oci et ext/oci8 ont été retirées du vote, Oracle prévoyant d’en assurer la maintenance dans le futur.

RFC: Replacing current json extension with jsond

Cette RFC proposait une modification tournant autour des extensions de manipulation de JSON.

En effet, le parser JSON actuellement utilisé par l’extension ext/json a une licence non-libre, qui pose problème à certaines distributions, et l’extension ext/json en elle-même est vieille, pas optimale et peu maintenue.

Cette RFC proposait donc de remplacer l’extension ext/json par du code basé sur l’extension ext/jsond, actuellement disponible via PECL.

La RFC donnait quelques points isolés qui vont partir en BC-break (notamment au niveau des flottants) ainsi qu’un lien vers des résultats de benchmarks.

Les votes ont été ouverts le 26 janvier 2015 pour être clôturés le 1er février 2015. Corriger les problèmes de licence nous semblant important pour un logiciel libre, nous avons exprimé un avis positif sur internals@.
La RFC a été adoptée à l’unanimité, avec 32 voix contre 0.

RFC: Default constructors

Voici une petite RFC qui visait à simplifier notre vie : default constructors.

Cette RFC proposait que, dans le constructeur d’une classe, il soit toujours possible d’appeler parent::__construct(), quelque soit la classe parente, y compris si celle-ci ne définissait pas explicitement de constructeur.
En somme, l’appel de parent::__construct() n’échouerait plus jamais.

Une fois cette idée implémentée, une classe enfant pourrait appeler le constructeur de sa classe parente, même si celle-ci n’en a pas.
Et le jour où un constructeur serait ajouté à la classe parente, il serait alors effectivement appelé — sans que nous n’ayons à repasser sur toutes ses classes enfant pour ajouter cet appel (comme nous devons le faire aujourd’hui).

Cela aurait également facilité les choses pour certaines classes fournies par PHP : en général, on dit que lorsqu’une classe de PHP est étendue en espace utilisateur, la classe fille doit impérativement appeler le constructeur de la classe parente fournie par PHP… Sauf que certaines de ces classes fournies par PHP n’ont pas de constructeur. C’est donc au développeur d’aller chercher, au cas par cas, s’il doit ou non appeler celui-ci.
Avec cette RFC, il ne serait plus nécessaire de s’interroger, puisqu’il deviendrait systématiquement possible d’appeler le constructeur de la classe parente, qu’il soit ou non défini.

Les votes ont été ouverts le 17 janvier 2015 et clôturés le 24 janvier 2015 et nous avons exprimé un avis positif (de peu) sur internals@.
Une majorité au 2/3 de oui était requise pour l’adoption de cette RFC, mais un résultat de 27 voix pour et 20 contre a décidé de son rejet.

RFC: Remove hex support in numeric strings

Voici une RFC qui proposait de supprimer le support des nombres hexadécimaux dans certains contextes.

En effet, aujourd’hui, utiliser des nombres hexadécimaux dans une chaîne est supporté (ils sont reconnus comme des nombres) dans certains cas (is_numeric(), par exemple), mais pas d’autres (casts int et float, notamment).

Cette RFC proposait donc d’uniformiser les choses en supprimant le support des nombres hexadécimaux dans des chaînes de caractères là où ils sont aujourd’hui reconnus :

  • Fonction is_numeric()
  • Opérandes des opérateurs ==, +, -, *, /, %, **, ++ et --
  • Paramètres de fonctions internes convertis en entiers
  • Peut-être quelques autres cas rares.

Quelques exemples plus détaillés sont disponibles sur la page de la RFC.

Les votes ont été ouverts le 17 janvier 2015 pour être clôturés le 27 janvier 2015 et même si nous n’avons été que peu nombreux à participer à la discussion, nous avons posté favorablement sur internals@.
La proposition a été adoptée à l’unanimité (29 voix contre 0).

RFC: Return Type Declarations

L’idée avait déjà été évoquée alors que PHP 5.6 était en cours de préparation — peut-être via une RFC pour 5.7.
En tout cas, voici le retour de cette proposition, mise à jour par rapport à la branche master, avec la RFC : Return Type Declarations.

Pour faire simple : cette RFC proposait de mettre en place la possibilité de spécifier un type de retour pour les fonctions et méthodes. Ce type de retour serait, bien sûr, optionnel : s’il est spécifié, il devra être respecté, mais s’il n’est pas présent, les choses fonctionneront comme aujourd’hui (on retrouve la logique déjà en place sur le type-hinting de paramètres).

Avec la syntaxe proposée, il deviendrait possible de déclarer, par exemple, qu’une fonction retourne toujours un tableau :

function foo(): array {
    return [];
}

Bien entendu, cette fonctionnalité est également branchée dans l’API de Reflection.

Les votes ont été ouverts le 16 janvier 2015 et clôturés le 23 janvier 2015 et nous avons posté un avis positif sur internals@.
La RFC a été adoptée par 47 voix contre 3 et il sera donc possible, avec PHP 7, de spécifier un type de retour pour les fonctions et méthodes !