mageekblog

Après près de 40 jours de relative inertie, il y a eu beaucoup de mouvements sur le trunk de PHP ces derniers temps, avec parfois des pointes à plus de 20 modifications par jour.

Pour rappel, le trunk de PHP contient le code de ce qui deviendra la prochaine version majeure du langage.

La dernière grosse modification est la disparition de la directive safe_mode du trunk, près de 5 ans après que la décision fut prise.

Pour rappel, il a été décidé de supprimer cette fonctionnalité car elle donnait un sentiment erroné de sécurité aux utilisateurs du langage et qu'en conséquence ces derniers ne sécurisaient pas correctement leur développement.

En effet, il est impossible de sécuriser complètement du code à l'aide d'un mécanisme de ce type et une grosse partie du travail reste obligatoirement à la charge des développeurs.

Évidement, on peut être d'accord, ou non, avec ce raisonnement, mais dans tous les cas, le fait que ce soit devenu effectif dans le trunk aussi longtemps après la prise de décision est très révélateur du bourbier dans lequel se trouvait le développement de PHP encore récemment.

Le code des traits a également subit plusieurs remaniements afin de faciliter son intégration dans le moteur de PHP.

Cependant, il reste toujours des questions en suspend sur ce sujet, et pour l'instant, le code n'est pas prêt à entrer en production.

Il y a eu de plus beaucoup de nettoyage effectué au cours de ces 10 derniers jours, avec la mise à jour ou la correction de plus de 400 tests, le colmatage de plusieurs fuites de mémoire, notament au niveau du pilote natif pour mysql aka mysqlnd et l'utilisation de fonctions plus efficace au niveau de mécanismes internes au langage.

Par ailleurs, les bugs #49490, #49081, #51721, #48289, #51732, #51723, #51273, #51690, #51289, #51719, #51688, #51688, #51691, #29828, #51128, #51671, #48361, #51374, #51670, #49723, #51582 et #51532 ont été résolus.

Enfin, la version du trunk n'est plus compilable à l'aide de Visual C++ dans les versions 6, 7 et 8 et ne supporte donc plus ce dernier que dans ses versions supérieures ou égales à 9.

Si le trunk a été relativement actif, internals@ a été beacoup plus calme, du moins jusqu'à ces deux derniers jours.

Dans les premiers jours, outre quelques résultats concrets sur l'amélioration des performances offerte par le code du trunk, Il y a eu deux comiques personnes qui ont essayé de mettre de l'ambiance en trollant revenant sur l'utilisation de \ comme séparateur pour les espaces de nommages et sur le nom de l'opérateur de résolution de portée :: aka. T_PAAMAYIM_NEKUDOTAYIM, mais ils n'ont guère tenu la distance.

Par contre, les deux derniers jours ont été beaucoup plus intéressants, puisqu'une RFC pour que PHP supporte la notion d'autoboxing a été proposée.

Pour résumer, cette fonctionnalité permettrait à l'aide d'une fonction de transformer un type natif tel qu'un entier, un flottant ou un tableau en un objet lorsque la variable qui lui correspond est utilisée comme un objet, de la manière suivante :

...
class IntObject {
   private $value;
 
   function __construct($value) {
      value = $value;
   }
 
   function upTo($upper_bound) {
      return range($this->value, $upper_bound);
   }
}
 
function __autobox($value) {
   if (is_int($value)) {
      return new IntObject($value);
   }
   return null;
}
 
// Test code
$val = 1;
var_dump($val->upTo(10) == array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10));
...

Pour l'instant, l'accueil fait à cette proposition est plutôt favorable, même si le spectre des problèmes posés par __autoload() lors de son intégration dans le langage plane au-dessus d'elle.

Il y a également une grosse discussion en cours pour résoudre le bogue #35050, répertorié depuis novembre 2005.

En effet, la lettre I aka i majuscule n'est pas reconnu par le moteur de PHP dans les noms de fonctions, classes, interfaces et méthodes lorsque la locale correspondant au turque ou l'azeri est définie car elle correspond à la lettre ı aka i minuscule sans point dans ces locales, et non à la lettre i minuscule telle que nous la connaissons.

En conséquence, PHP se retrouve incapable de résoudre le nom de la fonction/classe/interface/méthode appelée dans le code et provoque une erreur fatale.

Pour l'instant, trois solutions différentes ayant des impacts variés sont proposées, et un vote est en cours pour définir celle qui sera adopté dans la prochaine version de PHP.

Je vous donnerais donc dans 10 jours la solution qui aura été définitivement retenue, ainsi que ses conséquences éventuelles sur votre code.