Afin de ménager le suspense, je vais commencer, une fois n'est pas coutume, par le moins intéressant, à savoir les corrections de bugs, qui représente un peu moins de 25% des modifications.

Ainsi, les bugs #51991, #51276, #50101, #51168, #51273, #52001, #51822 et #52010 ont été corrigés, le plus important étant à mon sens le #51991 qui concerne spl_autoload().

Un test, que PHP ne passe pas pour le moment, a par ailleurs été ajouté dans le but de corriger le bug #39863, qui concerne file_exists().

Dans la continuité des corrections de bugs, le code a comme d'habitude été nettoyé par de petites corrections et optimisations qui permettront de compiler le langage plus facilement ou de supprimer des erreurs lors de la compilation.

Dans un tout autre registre, Pierre Joye a amélioré la fiabilité du générateur de nombre aléatoire du langage sous windows, afin de sécuriser un peu plus les sessions.

Du coup, la version du trunk de  PHP pour windows dispose maintenant également des directives session.entropy*.

L'implémentation des traits poursuit quant à elle son cours, avec la prise en compte des variables statiques de classe.

Cependant, tout cela n'est que du petit lait par rapport à l'implémentation du déférencement des tableaux (sic) lorsqu'ils sont en valeur de retour d'une fonction ou d'une méthode.

En effet, sous ce terme barbare, issue de ma traduction très personnelle de la RFC correspondante, se cache une amélioration syntaxique très demandée depuis très longtemps, à savoir la possibilité d'accèder à l'index d'un tableau directement lorsque ce dernier est le résultat d'une fonction ou d'une méthode.

En clair, il est maintenant possible de faire avec la version du trunk cela :

<?php

function fruit ()
{
return array('a' => 'apple', 'b' => 'banana');
}

echo fruit()['a']; // apple

?>

Cerise sur le gâteau, le chaînage est supporté, de la manière suivante :

<?php

class foo {
public $array = array();

public function __construct() {
$this->array = array(1, 2.3);
}

public function bar() {
return $this->array;
}
}

$foo = new foo;
var_dump($foo->bar()[1]); // float(2.3)
$foo->array[] = $foo;
var_dump($foo->bar()[2]->bar()[2]->array[0]); // int(1)

?>

Les choses pourraient de plus ne pas s'arrêter là, puisqu'il y a actuellement une discussion pour supporter cela :

<?php

$result = new (ResultMaker()->getIt());
// or
$result = (new ResultMaker())->getIt();

?>

Cependant, comme le montre l'exemple ci-dessus, il y a débat par rapport à la précédence de new par rapport aux parenthèses, et en conséquence, tant que cette ambiguïté n'est pas réglée, il y a peu de chances de voir une implémentation arriver dans le trunk.

Malgré cela, cet ajout a été unanimement salué sur internals@, qui est par ailleurs toujours engluée dans le débat concernant le contrôle du type des arguments, malgré plusieurs demandes de vote de la part de Lukas Kahwe Smith afin que la question soit réglée une bonne fois pour toute.

Lukas Kahwe Smith suit en effet de très prés le débat, malgré l'annonce de son départ de la communauté des contributeurs.

Il est difficile de dire si c'est parce qu'il est l'auteur de l'une des RFC sur le sujet, ou s'il ne s'agissait que d'un faux départ, mais dans tous les cas, il est fidèle à sa réputation de process guy et tente de structurer le débat.

En parlant de débat, celui concernant l'intégration dans les pilotes de PDO de fonctionnalités spécifiques au SGBD sous-jacent est apparament terminé, puisque des fonctions spécifique à postgresql ont été ajoutées dans le pilote PDO correspondant.

J'ai par ailleurs eu la satisfaction d'apprendre toujours via internals@ qu'il serait techniquement possible de modifier le moteur de PHP afin de pouvoir définir la valeur d'une constant à l'aide d'une expression, de la manière suivante :

<?php

namespace foo\bar\directories {
const tmp = __DIR__ . '/tmp';
}

?>

Je sais donc maintenant que si j'arrive à en trouver le temps, cela vaudra le coup que je me replonge en profondeur dans le code du Zend Engine.

Enfin, Dieu Rasmus Lerdorf a dernièrement proposé de modifier PHP-FPM afin de pouvoir l'interfacer facilement avec Gearman.

PHP n'étant pas parallélisable, puisqu'il ne gère pas les threads, la solution passerait par l'affectation d'un processus FPM à un script PHP spécifique correspondant à une tâche dévolue à Gearman.

J'avoue que l'idée est intelligente, mais je pense qu'il est dommage de limiter une telle fonctionnalité à PHP-FPM.

J'ai bien évoqué le threading comme alternative plus généraliste, mais comme d'habitude, la colère divine a frappé Ramus a refusé net l'idée.

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