Et pour ménager un peu le suspense, je vais donc commencer par vous parler très logiquement des modifications faites sur la version de développement, et que l'on pourra appelé peut être dans quelques mois PHP 5.4.

La modification plus importante concerne le paramètre de compilation--enable-zend-multibyte, qui permettait à PHP de détecter les scripts au format Unicode et qui devait être explicitement activé lors de la compilation du langage.

Il a maintenant disparu et il est remplacé par la directive de configuration zend.multibyte, accessible via le fichier php.ini, et la détection des scripts encodés à l'aide d'Unicode est dorénavant activée par défaut.

J'avoue que cette modification m'effraye un peu, car j'ai déjà rencontré des problèmes, notamment au niveau des archives PHAR, lorsque ce paramètre de compilation était activé, sans avoir jamais pu en connaître ou en découvrir la raison.

J'espère donc que le fait que le mécanisme de détection automatique de l'encodage soit maintenant activé par défaut ne posera pas de problèmes.

Autre modification intéressante, effectuée suite à la requête #53427, les clefs associatives d'un tableau passé en premier argument de stream_select() sont maintenant conservées.

Il faut cependant noter que cette modification ne pourra être effectuée dans PHP 5.3, pour des raisons techniques.

Par ailleurs, dans un registre plus modeste, les bugs #52854, #51901, #51003, #35547, #53377, #46587, #53352, #53403, #46587, #53304, #53407, #52501, #53409, #52327, #53420, #52828, #52656 et enfin #52202 ont été résolus.

Un bug a de plus été corrigé dans la révision 305754 sur la correction du bug #46587, et comme d'habitude, je n'ai pu m'empêcher de sourire à la lecture du commentaire associé :

Fixes the fix for bug #46587.

Et comme d'habitude, il y a le lot de petites optimisations diverses qui ne correspondent pas à un rapport de bug, sans oublier évidement les nettoyages effectués sur le code pour supprimer des alertes à la compilation ou bien pour respecter les conventions de codage.

Les affaires courantes étant maintenant expédiées, nous allons pouvoir maintenant rentrer dans le vif du sujet, à savoir ce qu'il se passe actuellement sur la liste de diffusion des contributeurs.

Plusieurs discussions, plus ou moins importantes, sont en cours et concerne à la fois le développement du langage et ses fonctionnalités.

Tout d'abord, une RFC visant à formaliser le processus de création d'une nouvelle version du langage a été proposée par un groupe de huit développeurs relativement influant au sein de la communauté des contributeurs.

Fraîchement accueilli dans un premier temps par les traditionalistes, il semble que la discussion évolue dans le bon sens et soit constructive, d'autant que cette RFC a reçu le soutient d'Andi Gutmans, l'un des deux créateurs du Zend Engine ainsi que celui de Lukas Kahwe Smith, l'ex monsieur formalisme de PHP puisqu'il a quitté le projet il y a maintenant quelques mois.

Il faut dire que les contributeurs peinent à sortir une version alpha de PHP 5.4 et que cette RFC arrive donc à point nommé.

Initialement prévue pour le 24 novembre, cette version alpha n'est toujours pas disponible, du fait d'un manque de consensus sur certaines fonctionnalités emblématiques de la prochaine version, comme le contrôle du type des arguments numériques lors d'un appel de fonction ou de méthode, la suppression des magic quotes, la cassure de la compatibilité avec les versions antérieures ou bien encore sur une chose aussi basique que le numéro de la version.

De plus, les traits ne semblent pas encore être totalement opérationnels, car certain cas exotiques ne sont pas correctement gérés, et si la dernière version d'APC compile lorsqu'il est intégré dans le code de PHP, il n'est pas fonctionnel.

Bref, les contributeurs ne sont pas près de voir le bout du tunnel en ce qui concerne PHP 5.4, et cela d'autant plus que l'outil de gestion de version qui est utilisé par la communauté des développeurs, à savoir subversion, ne permet pas d'extraire facilement du trunk les fonctionnalités indésirables afin de générer cette fameuse version alpha.

Pierre Joye, également parmi les auteurs de la RFC relative au processus de création d'une nouvelle version du langage, a donc proposé de migrer de subversion vers un système de gestion plus adapté au processus de développement de PHP, j'ai nommé Git.

Là encore, la proposition a reçu un accueil mitigé, d'autant qu'il y a parmi les contributeurs des fans d'autres systèmes de gestion de version décentralisé similaire à Git, comme Mercurial.

Et contrairement à la précédente, cette proposition n'a pas reçu le soutien d'Andi, qui pense qu'il y a mieux à faire sur le projet actuellement.

Il est donc difficile de dire ce que tout cela va donner, mais les choses bougent, et de mon point de vue, plutôt dans le bon sens.

Parallèlement à ces discussions relatives au processus de développement, il y a également eu des débats au sujet des fonctionnalités du langage.

Ainsi, Felipe Pena, également partie prenante dans les RFC précédemment citées, a proposé de permettre l’accès aux propriétés et aux méthodes d'une instance de classe directement après son sa création, de la manière suivante :

<?php var_dump(new foo()->bar()->x); ?>

À contrario des précédentes, la RFC correspondante a reçu un accueil chaleureux d'emblée de la plupart des contributeurs, et elle semble bien partie pour être intégrée prochainement dans le trunk une fois que quelques détails syntaxiques auront été réglés.

Une RFC proposant de supprimer le mot-clef function au niveau des déclarations de méthodes dans une classe a également été rédigée.

Une déclaration de méthode pourrait alors prendre la forme suivante :

<?php

class Foo
{
public bar()
{
echo "Hello World";
}
}

?>

Si elle a été plébiscitée dans un premier temps, elle est maintenant contestée, notamment par les traditionalistes, car si elle était acceptée, cela compliquerait la maintenance du code, puisqu'il serait beaucoup moins facile de détecter une déclaration de méthode au sein d'un projet, sans parler des problèmes que cela poseraient aux outils de développement.

Enfin, une RFC proposant l'implémentation d'accesseurs à la manière de C# a été proposée :

<?php

class TimePeriod
{
private $seconds;

public $Hours
{
get { return $this->seconds / 3600; }
set { $this->seconds = $value * 3600; }
};
}

?>

Pour le moment, les avis sont mitigés à son sujet, et même si elle était finalement acceptée, la fonctionnalité correspondante ne serait pas intégrée dans la prochaine version du langage.

La communauté des développeurs de PHP est donc en pleine ébullition suite à une série d'offensives du parti progressiste, ce qui est bien la preuve que le langage est bien vivant et dispose des ressources nécessaires pour évoluer dans le bon sens, n'en déplaise à ses détracteurs.

Cette rétrospective est maintenant terminée, vous pouvez reprendre une activité normale.