Je ne vais cependant pas mettre la charrue avant les bœufs, et je vais commencer par présenter le travail effectué sur le trunk de PHP, afin de garder le meilleur pour la fin.

Il y a eu un peu plus d'une cinquantaine de modifications effectuées sur le trunk au cours des vingts derniers jours.

La grande majorité de ces modifications sont des optimisations ou des corrections visant à éliminer des problèmes à la compilation ou bien à l’exécution.

Nous retrouvons donc le la litanie habituelle de corrections de bugs, puisque ceux correspondant aux identifiants #54108, #54092, #54089, #54118, #54167, #54193, #49608, #54152, #54180, #54242, #54242, #40510, #54247, #51958, #54262 et #54265 ont été fixés.

Parallèlement, des régressions apparues lors du développement ont été supprimées, des tests unitaires ont été ajoutés ou corrigés, et des optimisations ont été effectuées, notamment au niveau de l'extension SNMP.

Rien de bien croustillant donc à se mettre sous la dent, mais comme je l'ai déjà dit en introduction, la liste de diffusion des contributeurs, internals@, a été beaucoup plus intéressante, car très active.

La discussion au sujet de la RFC relative aux énumérations, commencée lors de la période précédente, s'est poursuivie, mais pour l'instant, il n'y a pas encore eu de consensus, que ce soit sur la nature d'une énumération, ou bien sur la façon de les implémenter au sein du langage.

Il faut dire que la discussion a dérivé à un moment donné sur le contrôle du type des arguments des fonctions et des méthodes, et que ce sujet est encore apparemment toujours très sensible au sein de la communauté.

De plus, d'autres débats ont débuté à propos de plusieurs nouvelles propositions, ce qui a en quelque sorte étouffé celui concernant les énumérations.

Ainsi, il a été proposé d'utiliser l'algorithme de Voltnitsky dans les fonctions permettant de localiser une sous-chaîne dans une chaîne de caractères, car il est censé être plus efficace que celui utilisé jusqu'à présent, notamment dans le cas de longues chaînes.

Dans l'absolu, cette suggestion a été accueillie favorablement, même si les contributeurs sont relativement frileux du fait de la jeunesse de l'algorithme.

Une RFC visant à intégrer un serveur HTTP au sein de PHP via l'interface en ligne de commande, aka CLI, a également été rédigée.

Elle a reçu un accueil chaleureux, notamment de la part de Dieu Rasmus Lerdorf, ce qui explique peut être son succès auprès des autres contributeurs.

Cependant, des limites très claires concernant les cas d'utilisation de ce serveur ont été posées.

En effet, , si jamais il est un jour effectivement intégré au langage, il ne sera conçu que pour être utilisé en phase de développement et aucunement en production.

Il a également été proposé d'utiliser le concept d'encapsulation au niveau des classes, ce qui permettrait de rendre ces dernières publiques, internes et privées.

Pour le moment, le concept a été jugée intéressant par quelques développeurs, mais il semble nécessaire de pousser un peu plus loin la réflexion initiale afin de comprendre toutes les implications, et d'autres s'interroge sur son utilité.

Il a également été demandé d'ajouter aux flux le support des méta-données liées à des fichiers, ce qui permettrait d'utiliser ces derniers avec des fonctions telles que chmod(), chown() ou bien encore touch().

Cette suggestion a provoqué une petite bataille rangée au sein de la communauté.

En effet, techniquement, il est très délicat, voir impossible, d'implémenter un support exhaustif à ce niveau pour tout les systèmes d'exploitation et l'ensemble des systèmes de fichiers existant.

Un camp milite donc pour une implémentation à minima, qui permettrait de manipuler les méta-données d'un fichier à l'aide d'un flux pour les configurations les plus répandues, tandis que l'autre ne veut pas en entendre parler, car cela pourrait potentiellement poser des problèmes à l'avenir.

Finalement, après quelques échanges tendus entre les leaders de chaque camp, Dieu Rasmus Lerdorf a, pour une fois, tranché dans le vif en proposant que chaque camp rédige une RFC, afin de pouvoir choisir la meilleure solution en toute connaissance de cause aux alentours du 21 mars 2011.

Un autre débat a eu lieu concernant l'implémentation de l'interface \countable au niveau la classe \splFIleObject afin qu'un appel à sizeof() ou count() retourne le nombre le ligne contenues dans le fichier considéré.

Dans ce cas, si l'intérêt fonctionnel n'a pas été discuté, il n'a pas encore été trouvé de consensus au niveau de l'implémentation.

En effet, certain considère que ce n'est pas le rôle de sizeof() ou de count() de retourner ce type d'information mais plutôt celui d'une méthode nommé par exemple \splFileObjet::getLineCount(), alors que d'autres considère que ce n'est pas le rôle de la classe \splFileObject de gérer cette fonctionnalité, mais celui d'une autre classe qui n'existe pas encore.

Enfin, le débat sur les annotations a redémarré (coïncidence troublante, j'en avais justement parlé avec Pierrick Charron lors de la ConFoo quelques jours auparavant).

Cependant, la discussion n'est malheureusement pas allé très loin, même si celui qui a relancé la discussion semble très motivé.

Notre Olivier Hoareau national a de son côté demandé sur internals@ s'il était possible d'embarquer au sein d'un même exécutable un binaire PHP spécifique ainsi que le code PHP correspondant sous la forme d'un PHAR, le tout sous différents systèmes d'exploitation.

Il a reçu un certain nombre de réponses, mais aucune ne permet de résoudre l'ensemble du problème, même si winbinder semble être une solution sous Windows.

Dans un autre registre, la discussion concernant la possibilité de laisser au développeur la possibilité de définir le type de balise PHP qui sera utilisé dans un fichier a été relancée par l'auteur de la proposition.

Cependant, le débat a tourné court car la RFC correspondante n'existe pas dans le wiki et elle ne pourra reprendre que lorsqu'elle aura été ajoutée.

Et pour terminer, un vieux serpent de mer a refait surface durant ces vingts derniers jours.

En effet, historiquement, PHP supprime automatiquement l'éventuel caractère EOL présent après la balise fermante ?>.

Une nouvelle fois, ce comportement étrange a suscité une interrogation, qui a reçu la réponse habituelle.

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