La RFC: Add pecl_http to core avait pour objectif d’intégrer nativement à PHP 7 l’extension pecl_http. Cette extension permet de gérer des communications HTTP grâce à une implémentation orientée objet.

Néanmoins, la présence de curl permettant l’accès à la couche HTTP à bas-niveau ainsi que l’existence de bibliothèques comme Guzzle  apportant une implémentation orientée objet (en espace utilisateur, donc non liée au cycle de versions et de maintenance de PHP) nous a paru suffisant en l’état. De plus, l’extension pecl_http embarquait des dépendances qui seraient venues s’ajouter au cycle de maintenance de PHP. Nous avons donc posté en ce sens sur internals@.

Avec 9 voix pour et 23 voix contre, cette RFC a finalement été refusée : l’extension pecl_http restera disponible depuis PECL pour les intéressés, et ne sera pas distribuée avec PHP.

Il est désormais démontré que le temps de réponse de vos applications a un réel impact sur l’activité économique (taux d’abandon de commande, taux de rebond…). Dès lors, mesurer les performances de votre application n’est plus une bonne pratique, mais une nécessité pour la bonne santé de vos projets.
Venez découvrir comment l’outil Blackfire.io peut vous permettre de mesurer les performances de votre application, y compris en production et permettre d’augmenter sa qualité !

L'apéro PHP permettra de discuter autour de ce sujet, dans une ambiance conviviale. Les apéros PHP sont aussi l'occasion de faire connaissance avec les développeurs de la communauté PHP locale, d'échanger sur les pratiques de chacun et de bénéficier de l'expérience de la communauté.

Rendez-vous mardi 10 mars, à 19h, chez Etincelle Coworking (2 rue d'Austerlitz, Toulouse). Réservez votre place sur leur site, annoncez votre venue sur le site des aperos PHP.
Une bonne soirée à toute la communauté toulousaine !  

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

• URL : https://wiki.php.net/rfc/group_use_declarations
• Version cible : PHP 7

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

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.

Toutes les fin de mois¹, l’antenne lyonnaise de l’AFUP organise un ApéroPHP :

Les apéros PHP sont ouverts à tous, quelque soit le niveau, le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien, en fonction des envies de tout le monde.

Lors de l’Apéro du 25 février 2015, j’ai eu l’occasion de donner une présentation, où j’ai parlé des nouveautés apportées par PHP 7, la prochaine version majeure de notre langage de prédilection, ainsi que du processus d’évolution de PHP, notamment à travers la mailing-list internals@.

Les slides que j’ai utilisés comme support sont disponibles en ligne² : PHP 7 et processus d’évolution de PHP : slides de ma présentation à l’AperoPHP lyonnais du 25 février.

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.

• URL : https://wiki.php.net/rfc/skipparams
• Version cible : PHP 7

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 ».

This post should be available in English in a few days.

1468 messages ont échangés en janvier 2015 sur la mailing-list internals@ de PHP, soit quasiment le double des mois précédents — et d’ailleurs plus que tous les mois depuis que j’ai commencé à effectuer ces dépilages¹ ! Voici donc un mois riche en événements, avec beaucoup d’activité autour de PHP 7 !

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient :

Pour commencer, les votes se sont terminés sur la RFC: PHP 5.7 qui proposait la sortie d’une version 5.7 de PHP qui aurait allongé le support de la branche 5.x et ajouté des avertissements sur les fonctionnalités qui disparaîtront avec l’arrivée de PHP 7.

la suite...

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.

• URL : https://wiki.php.net/rfc/combined-comparison-operator
• Version cible : PHP 7

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.

Si l'appel à conférenciers orientait sa thématique en particulier vers le Cloud, ce sont aussi (et surtout) PHP, ses performances, ses spécificités, ses nouveautés, qui ont l'honneur de notre programmation. 

Nous retrouverons donc Thibault Lenclos et son retour d'expérience ARTE, Wim Godden et sa conférence "The promise of asynchonous PHP", Julien Pauli pour son talk "En route pour PHP7", François Zaninotto de retour avec "Frameworks : a History of Violence", et Oswald De Riemaecker pour "Coder votre infrastructure" au sein de notre programmation.

L'appel à conférenciers est toujours en cours : déposez vos propositions avant le 28 février, minuit, et ce qu'elles traitent du Cloud en particulier, ou de PHP en général. Partagez votre expérience !

Et notez dans vos agendas : PHP Tour Luxembourg 2015, les 12 et 13 mai à l'abbaye de Neumünster.