Et malheureusement, vous n'aurez pas de nouvelle version sous le sapin cette année.

En effet, la date de sortie de la version alpha de PHP 5.4 n'est toujours pas définie, et c'est même le silence radio complet sur ce sujet sur la liste de diffusion des contributeurs, internals@.

Pour autant, il y a eu des discussions, notamment au sujet :

  • de la désactivation des traitements effectués sur $_POST.
  • de la gestion des propriétés par les traits
  • de la possibilité de définir des macros directement dans le code PHP.
  • de définir le type des balises PHP lors de l'inclusion d'un fichier.
  • de la gestion des erreurs.

En ce qui concerne la désactivation des traitements sur la variable $_POST, le débat, débuté lors de la période précédente, porte sur le recours à une option de configuration au niveau du php.ini, le fichier de configuration du langage.

Pour l'instant, c'est cette solution a été retenue et implémentée dans le trunk, mais elle n'est pas du goût de tout le monde.

Il est donc possible que cela évolue, même si pour l'instant, aucune solution alternative n'a été proposée.

Les traits ont été également à l'ordre du jour, et plus particulièrement la façon dont ils doivent gérer les propriétés d'une classe.

Pour le moment, il a été décidé que si deux propriétés portant le même nom dans deux traits différents ne sont pas identiques, tant en terme de visibilité qu'au niveau de leur valeur par défaut, PHP générera une erreur fatale lors de la compilation du script.

Et si le mode strict est activé, un message sera émis pour décourager l'utilisation des propriétés dans les traits.

En effet, ces derniers sont indépendants de l'état des classes dans lesquels ils sont intégrés, et en conséquence, ils ne devraient pas faire appel directement à des propriétés mais utiliser des accesseurs.

Cela me rappelle furieusement un certaine certaine discussion sur ce blog...

Bref, la RFC correspondante a été mise à jour en fonction de ce qu'il est ressorti des discussions, mais le sujet est complexe et il n'est pas dit que tout cela ne change pas encore à l'avenir.

Dans un autre registre, la discussion commencé sur la période précédente concernant la possibilité de définir le type de balise PHP utilisées dans un fichier inclus se poursuit.

Les contributeurs recherchent la meilleure solution pour implémenter cette fonctionnalité, et il semble que l'on s'oriente vers l'utilisation d'un masque de bits afin d'avoir un maximum de souplesse, de la manière suivante :

2 - normal tags (<?php ?> )
4 - short tags (<? ?>)
8 - asp ( <% %> )
16 - Shorthand echo ( <?php=, <?=, <%= )
32 - Script tags (<script type="php"> </script> )

Enfin, comme je l'ai dis, il y a eu une proposition pour intégrer la possibilité de définir l'équivalent des macros C au sein du code PHP, de la manière suivante :

<?php

MACRO('PF','private function _');
MACRO('SCOPE_CLASS','class MyProject_');

class UseMacro {
   PF preSave($object) {
      //...
   }
}

SCOPE_CLASS Internal {}

?>

Pour l'instant, l'accueil n'a pas été des plus chaleureux, les contributeurs considérant en effet que cela rajoute une couche de complexité inutile au langage et que de plus, il existe des solutions externes comme le pré-processeur de gcc ou les systèmes de templates.

Enfin, une modification a été proposée pour la seconde fois pour améliorer en terme de performance la gestion des erreurs par le langage.

La première proposition sur ce sujet avait donné lieu à une discussion fleuve qui n'avait aboutie à rien, comme malheureusement bien souvent.

Pour l'instant, les débats sont beaucoup moins enflammés et un problème a été soulevé au niveau de la nouvelle implémentation proposée, problème qui ne semble pas avoir de solution.

Au niveau du trunk, il ne s'est pas passé grand choses de palpitant, certainement en raison de l'approche des fêtes de fin d'année.

L'utilitaire phpize semble maintenant être utilisable sous Windows, et les bugs #53541, #53568, #53527, #53574, #53579, #53588, #52209 et #53592 ont été corrigés.

Le reste des modifications concerne des corrections, du nettoyage et des optimisations, ainsi que les implémentations correspondant aux décisions prises sur internals@ dernièrement et dont j'avais déjà parlé dans le billet concernant la période précédente.

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

Et joyeux noël à tous !