Ce mois-ci sur internals@php - Avril 2014

This post is also available in English.

Le mois d’avril 2014 qui vient de se terminer a vu 355 messages sur la mailing-list internals@ de PHP – ce qui en fait un mois très calme, avec pas loin de moitié moins d’échanges qu’en mars.

Sous forme d’un graphique représentant le nombre de mails par mois sur les trois dernières années, on obtient (l’historique depuis 1998 est disponible ici) :

La tendance à la baisse du volume d’échanges, déjà entamée le mois dernier, se confirme : PHP 5.6 est en pleine phase de bêta – et donc, plus aucune fonctionnalité ne peut y être ajoutée. Les discussions se sont donc un peu calmées ; et elles ne sont pas encore complètement lancées sur la version suivante.

Le 10 avril, Ferenc Kovacs a annoncé que PHP 5.6.0beta1 avait été taggée – et elle a été publiée le lendemain !

Ce passage en phase de versions bêta marque le feature-freeze de PHP 5.6 : plus aucune nouvelle fonctionnalité ne peut désormais être ajoutée pour cette version.

En parallèle du passage de PHP 5.6 en phase de bêta, Julien Pauli a dressé une liste des points sur lesquels il estimait que la majorité était d’accord, pour la prochaine version majeure de PHP :

• une prochaine version majeure de PHP devrait être publiée ; aussi rapidement que possible,
• elle devrait être nommée “PHP 6”,
• lorsque c’est nécessaire, la compatibilité antérieure pourra être cassée, et cette version pourra introduire de nouvelles notions,
• la principale notion sur laquelle il faut se concentrer est Unicode,
• les idées évoquées jusqu’à présent ont été regroupés sur https://wiki.php.net/ideas/php6,
• et le développement se ferait par le biais d’une itération de deux ans.

Les prochaines étapes seraient alors :

• de commencer à rédiger des RFCs ciblées pour PHP 6 et d’échanger sur les idées correspondantes,
• ainsi que de créer la branche Git pour PHP 6.

Kris Craig a rapidement indiqué qu’il serait intéressant de passer à un workflow Git plus organisé que ce qui se fait actuellement. Son mail a été suivi d’une discussion sur ce qui se faisait actuellement, ainsi que sur le rôle des Release Managers par rapport aux fonctionnalités et à leur merge.

Alternativement, comme souligné par Nikita Popov, la branche master pourrait simplement jouer le rôle de prochaine version majeure, en ne créant une nouvelle branche de version que lorsque la release approchera.

En parallèle, Johannes Schlüter a suggéré qu’il serait intéressant de mettre en place un principe de merge des branches de release vers leurs branches parentes – sans que l’idée ne semble convaincre.

Eli a ensuite remis une couche sur la question du numéro que cette prochaine version devrait porter, en relatant le résultats de conversations qu’il a eu plusieurs fois avec des membres de la communauté.

D’après lui, PHP.next ne devrait pas s’appeler “PHP 6” : il existe trop de ressources parlant de “PHP 6” tel qu’il était pensé il y a cinq ans de cela – et retenir ce numéro de version serait source de confusion (il existe des livres – papier – sur “PHP 6”, par exemple ! Sans compter la quantité d’articles publiés sur le sujet¹, de slides de présentations données ici et là², …). Il ne faut pas oublier que la grande majorité des développeurs utilisant PHP ne fait pas partie de la communauté et ne sont donc pas toujours au courant de l’actualité.

Passer directement à “PHP 7” pourrait être une solution acceptable à ce “problème”, et ne devrait pas tellement nuire en terme d’image : “PHP 6”, aujourd’hui, serait déjà considérée comme une expérience ratée.

Bien sûr, tout le monde n’est pas d’accord avec cette proposition. Après tout, “PHP 6” n’a jamais été diffusée et s’est arrêtée à une branche de développement ! De plus, la communication entourant la sortie de la prochaine version majeure de PHP devrait rapidement recouvrir et masquer le plus gros de ce que l’on peut aujourd’hui encore trouver sur l’ancien PHP 6.

Et, en même temps, comme l’a souligné Trevor Suarez, il faudrait peut-être commencer à la coder, cette future version ; et le nom pourrait n’être choisi que lorsque la release approchera ^^

Stas Malyshev a essayé d’attirer l’attention sur le fait que les tests de PHP sur Travis CI ne restent jamais au vert bien longtemps – au point que l’état normal soit les tests échouent.

Une première étape, avant de corriger cela, serait d’accepter comme objectif, pour l’équipe de développeurs de PHP, que les tests doivent rester au vert. Ensuite, envoyer un mail à celui qui a cassé le build pourrait aider (la suite de tests de PHP est longue – et chaque développeur ne la relance pas en entier sur son poste à chaque commit).

Dans la suite de cette réflexion et en vue de la formaliser, Stas Malyshev a rédigé la RFC: Keeping PHPT Tests Green. Ferenc Kovacs a profité de la discussion pour proposer d’étendre la configuration Travis en vue de tester plus de points (plus d’extensions, plusieurs configurations de build de PHP, …). Bien sûr, idéalement, tout changement devrait être effectué via une branche, et les tests devraient être au vert sur celle-ci avant qu’elle ne soit mergée.

Les votes n’étaient pas terminés fin avril, mais les choses semblent aller dans le bon sens, avec une immense majorité de “pour”. Que faire en cas de test qui échoue est une question pour laquelle la réponse semble moins évidente – et il se pourrait qu’elle ne soit pour l’instant pas gravée dans le marbre et laissée à l’appréciation des RMs au cas par cas.

Levi Morrison a annoncé la RFC: Return Type Declarations, dont l’idée est de permettre, lors de la déclaration d’une fonction ou méthode, d’indiquer quel type de donnée elle doit retourner. Par exemple :

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

Ce n’est pas la première fois que cette idée est évoquée – et la RFC indique en quoi cette proposition est différente des précédentes.

Les premiers retours ont été plutôt positifs, d’autant que la RFC est bien ciblée et répond à un besoin plusieurs fois exprimé. De plus, cette proposition aiderait aussi au niveau du PHP-FIG, puisqu’il deviendrait possible de type-hinter aussi bien les retours que les paramètres des interfaces qu’il définit.

PHP 5.6 ayant atteint son feature-freeze, cette RFC cible PHP 5.7 ou PHP 6. Je suis curieux de voir comment les choses évolueront – mais au vu des échanges, l’idée me semble plutôt bien partie !

Leigh a demandé ce que les autres développeurs pensaient de l’idée de reconnaître des positions négatives dans des chaînes de caractères, pour obtenir des caractères à partir de la fin de celle-ci ; par exemple :

$string = 'foobar';
print $string[-1]; // prints 'r';
print $string[-2]; // prints 'a';

Les premiers retours ont été plutôt positifs, même si le fait d’utiliser la même syntaxe pour des tableaux et des chaînes de caractères peut être source de confusion pour l’utilisateur.

Bien sûr, cette proposition serait plus intéressante s’il était possible de spécifier un intervalle de positions, et plus la seule position d’un unique caractère :

"foobarbazbuz"[4:7] => "barbazb"
"foobarbazbuz"[4-7] => "barb"
"foobarbazbuz"[4,7] => ["b", "b"] 

Au final, en poussant un peu l’idée, on arriverait à ce que peut permettre Python ;-). Idée qui ne semble pas convenir à tous.

Le mois dernier, Jakub Zelenka avait commencé à travailler sur pecl/jsond, une nouvelle implémentation de parser JSON pour PHP. Il reste encore pas mal de tests à mettre en place et PHP 5.6 est passée en feature-freeze, donc l’intégration de cette nouveauté pourrait être ciblée vers PHP 5.7.

Timm Friebe a rédigé la RFC: Catchable “call to a member function of a non-object”, qui vise à obtenir une erreur non-fatale E_RECOVERABLE_ERROR lors d’une tentative d’appel sur autre chose qu’un objet – sur NULL, typiquement.

Rowan Collins a lancé une discussion autour de la gestion d’erreurs et d’exceptions de PHP, qui gagnerait à être revue pour PHP 6 (un changement de version majeure serait effectivement une bonne occasion). La discussion a beaucoup tourné autour de l’opérateur @ ; et sur le fait que les erreurs de PHP couvrent aujourd’hui de nombreux cas d’utilisation.

internals@lists.php.net est la mailing-list des développeurs de PHP ; elle est utilisée pour discuter des prochaines évolutions du langage, ainsi que pour échanger autour de suggestions d’améliorations ou de rapports de bugs.
Elle est publique, et tout le monde peut s’y inscrire depuis la page Mailing Lists, ou consulter ses archives en HTTP depuis php.internals ou depuis le serveur de news news://news.php.net/php.internals.