Cependant, avant de rentrer dans le détail de ces propositions, je vais, comme d'habitude, vous présenter les principales modifications subies par le trunk au cours de la période qui vient de s'écouler.

Tout d'abord, les bugs #52609, #52654, #52407, #52655, #52655, #52674, #52681, #52614 et #52699 ont été corrigés.

De plus, le comportement de la fonction array_combine() a été modifié, conformément à la demande #34857.

Cette dernière renverra donc dorénavant avec la prochaine version majeure du langage un tableau vide lorsqu'elle recevra deux tableaux vides en argument, au lieu de renvoyer le booléen false et de générer une erreur de type E_WARNING.

Le reste des modifications concerne notamment le module FastCGI, aka FPM, qui a été quelque peu optimisé et qui supporte maintenant les fonctions apache_child_terminate(), getallheaders(), apache_request_headers() et apache_response_headers().

Et bien évidement, il y a eu le lot habituel de corrections visant à nettoyer le code et à faciliter la compilation.

C'est donc clairement sur la liste des contributeurs, internals@, qu'il faut aller chercher les informations croustillantes.

Et il y en a eu, mais pas forcément croustillante dans le bon sens du terme.

Tout d'abord, il y a eu un énorme débat autour des contrôles effectués par PHP lors d'un héritage de classe.

En effet, ce dernier, conformément au principe de substitution de Liskov, refuse, si le niveau d'erreur E_STRICT est activé, qu'une méthode d'une classe fille surchargeant une méthode d'une classe parente dispose d'un nombre d'arguments inférieur.

Dans ce cas de figure, le langage génère alors une erreur E_STRICT, ce qui ne semblait pas du goût de tout le monde.

Il y a donc eu une discussion assez longue sur le sujet expliquant ce fameux principe et finalement, il semble que la situation soit maintenant claire et acceptée.

Il y a également eu une proposition visant à ajouter deux constantes à PHP, E_NONE et E_EVERYTHING.

E_NONE, comme son nom l'indique, a pour but de désactiver complètement la gestion des erreurs, et correspondrait donc à error_reporting(0).

E_EVERYTHING permettrait quand à elle l'activation de la gestion d'erreur à son niveau le plus élevé.

Autant le dire immédiatement, cette proposition n'a pas suscité un débat très intéressant.

En effet, si quelques réponses ont été intéressantes, comme celle visant a ajouter en plus E_DEVELPEMENT et E_PRODUCTION, à la manière de ce que fait Apache, la plupart ont été pour le moins ironiques, puisque certain ont proposé E_ALL_AND_I_REALLY_REALLY_REALLY_DO_MEAN_ALL et E_CHUCK_NORRIS.

En conséquence, il y a peu de chances de voir arriver ces constantes dans la prochaine version du langage, du moins pour le moment.

Enfin, il y a également un débat autour des annotations, suite à la proposition d'une solution technique par Pierrick Charron faisant suite à la RFC correspondante.

Pour simplifier, les annotations sont des méta-données, qui peuvent être utiliser afin de documenter ou manipuler le code.

La prochaine version majeure de PHP est donc susceptible de les supporter, de la manière suivante :

<?php

class TODO extends ReflectionAnnotation
{
const SEVERITY_CRITICAL = 1;
const SEVERITY_IMPORTANT = 2;
const SEVERITY_TRIVIAL = 3;
public $value;
public $severity = self::SEVERITY_IMPORTANT;
}

[TODO("I need to implement this class", severity=CustomAnnotation::SEVERITY_CRITICAL)]
class Test {}

[TODO("Review this one")]
class Test2 {}

?>

Il est ensuite possible de récupérer les informations véhiculées par les annotations à l'aide des classes de reflexion :

<?php

$class = new reflectionClass('Test');
var_dump($class->getAnnotations());
/*
array(2) {
["TODO"]=>
object(TODO)#%d (1) {
["value"]=>"I need to implement this class"},
["severity" => 1
}
}*/

?>

Les contributeurs sont donc en train d'étudier cette solution afin de la valider et les choses semblent avancer rapidement.

En effet, il y a bien quelques remarques, notamment sur le fait de recourir à un objet pour définir les annotations, mais rien de bien sérieux, et de plus, cette solution ne pose aucun problème de compatibilité avec l'existant.

Pour terminer, il y a eu également un message courageux signalant que le portage du threading sous Windows au sein de PHP avait été réalisé, pour faire suite à son implémentation sous UNIX.

Cependant, ce message n'a suscité aucune réaction au niveau des contributeurs.

Il faut dire que Dieu Rasmus Lerdorf clame haut et fort depuis des années que le threading ne présente aucun intérêt au niveau de PHP, et que la communauté des contributeurs soutient mordicus que c'est impossible à réaliser techniquement au niveau du Zend Engine...

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