Il n'y a donc pas eu de remises en cause, pour le moment, des décisions prises au cours de la période précédente, et pour l'instant, il semble bien que PHP supportera un jour les annotations sous la forme de commentaires dans le code.

Pour autant, d'autres décisions ont été prises, suite à des propositions ou à des questions posées sur la liste de diffusion.

Ainsi, les messages d'erreurs relatifs à l'analyse du code source d'un script vont (enfin) être amélioré afin d'être plus explicite.

La prochaine version du langage signera donc peut être bien la fin du fameux message d'erreur suivant :

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in Command line code on line 1

Il devrait en effet être avantageusement remplacé par :

Parse error: syntax error, unexpected :: in Command line code on line 1

Et plus généralement, les noms des symboles correspondant aux instructions du langage devrait être remplacé par un descriptif explicite, tel qu'expliqué dans la RFC correspondante.

La SPL, et plus généralement les constructeurs des classes qui la compose, ont également fait l'objet d'un débat.

En effet, la documentation indique que plusieurs de ses classes disposent d'un constructeur, ce qui ne réflète pas forcément la réalité.

C'est par exemple le cas de la classe \SplObjectStorage, et en conséquence, dans une classe dérivée de cette dernière, un appel au constructeur de la classe \SplObjectStorage génère une erreur :

<?php

class mySplObjectStorage
{
	public function __construct()
	{
		parent::__construct(); // provoque une erreur.
	}
}

?>>

La discussion a rapidement débordé du cadre de la SPL pour aborder le problème de manière plus globale.

Il en est ressortie que dans un premier temps, la SPL devrait être modifiée pour ajouter les constructeurs manquant, et que dans un second temps, il soit étudié la possibilité qu'un appel à un constructeur ou à un destructeur absent d'une classe parente ne génére plus d'erreur.

Dans un autre registre, le débat concernant l'avenir de la syntaxe <?= a également été relancé au cours de ces 10 jours.

Il était en effet prévu pour PHP 6 que la directive short_open_tags soit supprimée de PHP.

Or, la gestion de la notation <?= est actuellement dépendante de l'implémentation de cette directive, et cette notation est très utilisée.

Les contributeurs ont donc décidé de découpler les deux fonctionnalités afin de pouvoir supprimer la directive short_open_tags de la prochaine version du langage tout en conservant la notation <?=.

C'est d'ailleurs Dieu Rasmus Lerdorf lui-même qui a mis fin au débat en effectuant la modification nécessaire sur le trunk.

Cette période a également vu une amélioration des performances de PHP pour tout ce qui concerne les calculs arithmètiques, grâce à l'utilisation de directive de compilation spécifique.

Pour l'instant, seules les versions du langage compilée avec GCC pourront en bénéficier, mais il est prévu également le même type d'optimisation pour Visual Studio.

Le gain est de l'ordre de 10% lors de l'exécution d'un script spécifique destiné à mesurer les performances de PHP.

Cependant, pour des scripts ne faisant pas appel massivement à des calculs arithmétiques, soit la grande majorité des scripts existant, le gain n'est pas significatif.

Enfin, tout comme il sera possible d'écrire myFunction()['myKey'] avec la prochaine version du langage, il sera possible d'instancier un classe et d'utiliser l'instance créer dans la foulée, sans passer par une variable intermédiaire :

<?php

new \myClass()->doSomething();

// Remplace :
// $instance= new \myClass();
// $instance>doSomething();

?>

Le trunk a quand a lui été modifié une soixantaine de fois sur la période qui vient de s'écouler.

Parmi ces modifications, il y a évidemment le lot habituel de corrections, puisque les bugs #42060, #50363, #53782, #54269, #54529, #54721, #54727, #54804, #54895, #54912 et #54924 ont été corrigés.

Des fuites de mémoire ont par ailleurs été colmatées, grâce à la mise en œuvre de parfait, un outil d'analyse de code C/C++ développé par Oracle pour détecter entre autre ce genre de problème.

Par ailleurs, l'interface FPM et le support de MySQL, via des corrections et des optimisations sur mysqlnd, mysql, mysqli et PHP Data Object">PDO, ont été les plus gros bénéficiaires du travail effectué par les contributeurs sur ces 10 jours.

Enfin, Suite à la demande de Dieu Rasmus Lerdorf lors de la période précédente, les tests unitaires du trunk continuent à être corrigés.

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