Tout d'abord, la prochaine version de PHP ne sera plus du tout compatible avec PHP3, puisque le dernier morceau de code chargé d'assurer cette compatibilité a été supprimé du trunk.

Je sais, vous êtes tous très triste d'apprendre cette information de toute première importance...

Cependant, je vous rassure, toutes les nouvelles que j'ai à vous annoncer n'auront pas cet impact phénoménal sur nos vies de développeur.

Ainsi, les constructeurs à la façon de PHP4 ne seront plus supportés dans la prochaine version.

Avant PHP5, le constructeur d'une classe était une méthode qui portait le nom de la classe.

Depuis PHP5,  le constructeur d'une classe est une méthode qui doit porter le nom de __construct.

Cependant, pour des raisons de compatibilité, le comportement de PHP4 avait été conservé.

Du coup, dans certaine configuration, si un développeur définit une méthode de classe portant le nom de la classe, le langage lance le message d'alerte suivant :

 PHP Strict Standards: Redefining already defined constructor for class foo\bar in [snip file] on line [snip line]

Pour résoudre le problème, il a donc été décidé de supprimer de la prochaine version le support des constructeurs à la façon de PHP4.

Il est à noter cependant que cette solution ne résoud qu'un seul des deux problèmes soulevés par le message posté sur internals@.

En effet, pour l'instant, il ne sera toujours pas possible de définir une classe array dans la prochaine version de PHP.

Ces 10 jours ont également vu le retour d'un vieux serpent de mer, à savoir une demande pour que le langage supporte le multithreading, à la façon de Perl, Python ou ruby.

Il faut en effet savoir que PHP ne supporte pas du tout les threads, au contraire des langages précédemment cités.

La réponse a été claire et tient en deux arguments :

  1. Cette fonctionnalité n'a aucun intérêt.
  2. Implémenter cette fonctionnalité implique une réécriture compléte du Zend Engine.

Je vous laisse tirer vos propres conclusions...

Par ailleurs, la discussion continue toujours au sujet des traits et des grafts, et pour l'instant, il n'y a toujours pas de décision prise, même si les choses avancent puisque la définition sémantique d'un traits ou d'un grafts a bien avancé, et que les avantages des uns et des autres commencent à être clairement défini.

Une discussion a également débuté au sujet des paramêtres nommés, certainement dérivée de celle au sujet de l'initialisation rapide de propriétés d'une instance de classe, puisque l'un est évoqué dans l'autre.

Dieu Rasmus ayant déclaré qu'il n'était pas contre l'introduction de cette fonctionnalité, à la condition qu'une implémentation propre puisse être trouvée, et cela même s'il n'en voit pas l'intérêt, peut-être qu'il est probable qu'un jour nous disposions éventuellement de cette fonctionnalité dans une des prochaines versions du langage.

Accessoirement, l'ambiance sur la liste internals@ n'a pas changé durant mon absence de plus de trois ans.

Il est en effet toujours possible de croiser au détour d'un message une marque de respect et d'affection envers son prochain, et pour un peu, il serait presque possible de se croire au pays des Bisounours :

ROFLMAO. You can stick your RFCs where sun does not shine. I will not contribute anything as long as you're acting like some project manager.